Le projet en un coup d’œil
Clients, commerciaux, administration, Odoo, stock, finance et logistique devaient lire et faire évoluer la même réalité.
Dawap a construit le portail client, le cockpit commercial et l’administration, reliés par 25 flux Odoo et des domaines partagés.
Catalogue, prix, commande, finance, achats, disponibilité, livraison, IA et qualité forment désormais un système observable.
Ce projet commence comme une question de site B2B et finit comme une transformation du système commercial. Car un client ne voit jamais seulement une interface : il voit un catalogue qui doit lui appartenir, un prix qui doit être le sien, une disponibilité que l’entreprise peut tenir, une commande qui doit traverser l’ERP et une livraison dont les équipes doivent pouvoir expliquer chaque étape.
Dawap et 1UP Distribution ont consolidé cette chaîne en un produit structuré. Le portail client donne de l’autonomie. Le cockpit commercial relie la relation aux faits. L’administration pilote les référentiels et le run. Odoo reste au cœur des objets contractuels. La disponibilité, le pilotage logistique et six assistants IA ajoutent les capacités que l’ERP seul ne devait pas porter.
L’enjeu n’était pas d’empiler ces modules, mais de leur faire partager les mêmes identités, règles et preuves. Une entreprise confrontée au même type de fragmentation peut partir de notre offre d’application web connectée à un ERP ou CRM ; les approfondissements reliés à ce cas permettent ensuite d’examiner chaque problème dans sa réalité opérationnelle.
Un programme, huit projets complémentaires
Chaque projet part d’une souffrance métier précise et montre la réponse effectivement livrée. La vue d’ensemble relie le portail client, le cockpit commercial, Odoo, la commande, la logistique, l’IA et le socle d’industrialisation.
1. 1UP Distribution, un commerce B2B déjà riche
Transformer sans effacer les systèmes et pratiques qui font tourner l’activité
1UP Distribution est un client historique de Dawap. Plusieurs briques existaient déjà : site B2B connecté à Odoo et Algolia, automatisation de commandes, sourcing, flux e-commerce et hub ShippingBo/Odoo/Wix. La transformation n’est donc ni une page blanche, ni une refonte cosmétique.
La difficulté consistait à faire évoluer un patrimoine vivant. Les comptes, commandes, produits, documents et flux existants devaient continuer à fonctionner pendant que les workspaces, le domaine, les projections et les outils d’exploitation étaient reconstruits et enrichis.
Le projet plateforme B2B connectée à Odoo et Algolia constitue le point de départ de cette histoire. Le hub ShippingBo, Odoo et Wix montre une autre étape de l’écosystème. Le travail présenté ici documente la transformation plus large et son industrialisation.
2. Piloter un programme, livrer des parcours
Découper par valeur sans perdre la cohérence du système
Dawap a organisé le travail par domaines et parcours verticaux. Chaque sujet part d’une souffrance, traverse les règles, les données, les intégrations, l’interface, les tests et le déploiement. Cette méthode évite qu’un chantier “front” et un chantier “ERP” produisent deux vérités incompatibles.
Le backlog Jira a été conduit en sprints avec démonstrations, arbitrages et consolidations fréquentes. Les sujets ont été ordonnés selon la valeur du parcours livré, ses dépendances et le risque opérationnel retiré. Une capacité transverse n’était ouverte que lorsque ses maillons essentiels formaient un parcours vérifiable : par exemple offre, prix, disponibilité, panier, import et reprise pour la commande.
La qualité suit la même logique incrémentale. Un lot n’est pas terminé parce qu’un écran fonctionne : les cas d’échec, scopes, contrats, files, replays, métriques et runbooks entrent dans la définition de fini selon le risque. Les limites non encore prouvées restent marquées comme NO-GO.
3. Avant la transformation
Des briques utiles, mais une activité encore trop fragmentée
1UP Distribution disposait déjà d’un patrimoine numérique conséquent. Les développements précédents avaient relié le commerce à Odoo, Algolia, ShippingBo, Wix et d’autres opérations. Ces réalisations avaient créé de la valeur, mais aussi révélé le besoin d’un socle plus unifié pour le B2B.
Les clients avaient besoin d’un espace plus autonome et contextualisé. Les commerciaux devaient recouper plusieurs vues pour comprendre un compte. Les administrateurs manipulaient des référentiels, flux et projections dont les responsabilités n’étaient pas toujours aussi lisibles qu’elles devaient l’être.
La croissance fonctionnelle augmentait aussi le coût de changement. Un même concept — compte, produit, prix, stock ou commande — traversait l’ERP, l’interface, les APIs et les analyses. Sans frontières et contrats plus nets, chaque nouvelle capacité risquait de créer une nouvelle variante de la vérité.
La transformation part de ce constat : ne pas jeter l’existant, mais lui donner une architecture, des parcours et des preuves capables de soutenir la prochaine étape.
Le vrai problème : cinq versions plausibles de la même commande
Le portail pouvait connaître l’intention, Odoo l’objet contractuel, la logistique l’engagement physique, la finance le document et le commercial la conversation. Chacune de ces lectures est légitime ; le risque apparaît lorsqu’elles ne partagent plus l’identité qui permet de les rapprocher.
La transformation devait donc conserver les différences utiles sans laisser naître des histoires concurrentes. Une commande locale n’est pas encore une commande Odoo, une quantité physique n’est pas une disponibilité commerciale et une alerte n’est pas une décision.
Faire évoluer un système vivant sans interrompre le métier
Les données historiques, les intégrations et les habitudes des équipes ne pouvaient pas être suspendues pendant une reconstruction idéale. Chaque lot devait cohabiter avec l’existant, reprendre les identités déjà attribuées et fournir un chemin de retour lorsque la migration touchait un flux critique.
Cette contrainte a guidé le delivery vertical : sécuriser un parcours complet, le valider sur l’environnement prévu, observer sa transition puis seulement étendre le périmètre. La refonte devient une succession de gains exploitables plutôt qu’un basculement aveugle.
4. Une vision : un système commercial B2B connecté
Relier l’expérience, l’opération et la source de vérité
La vision cible distingue les responsabilités. Odoo porte les objets contractuels et financiers. La plateforme construit les expériences client et commerciales, les états de traitement, les projections et les outils d’exploitation. Les APIs et messages relient ces mondes avec des identités et des contrats.
Les domaines structurent le produit : CRM, catalogue, panier, ventes, achats, disponibilité, livraison, finance, IA, sécurité et monitoring. Chaque domaine prend ses décisions et expose des ports. Les contrôleurs et adaptateurs ne réinventent pas les règles.
Cette architecture permet de faire évoluer un canal sans cloner le métier. Le portail client, le commercial externe et l’administration peuvent présenter un catalogue différent, mais le produit résout la distribution, le prix et la disponibilité depuis des services communs.
La transformation correspond à une application métier sur mesure à plusieurs visages, connectée au SI et conçue pour rester exploitable.
Client, commercial et administration
Catalogue, prix, commande, stock et finance
APIs, messages, workers et identités
Odoo, recherche, transport et modèles IA
Preuves, alertes, replay et amélioration
5. Trois workspaces, trois responsabilités
Client, commercial et super-administration sans confusion de rôles
L’espace client B2B rend autonomes l’onboarding, le compte, le catalogue, le prix, le panier, les commandes, les documents et l’aide. Il masque la profondeur technique, mais jamais au prix d’une fausse promesse.
Le workspace commercial regroupe portefeuille, CRM opérationnel, catalogue, prise de commande, devis, ventes, expéditions, factures, avoirs, pipeline, radars et reporting. Il relie la relation client à l’exécution.
La super-administration pilote le catalogue, les distributions, la qualité des données, le CRM, les achats, les ventes, le radar, le reporting, les flux, les assistants et le monitoring. Elle donne aux équipes capables d’agir les détails que les autres espaces n’ont pas besoin de voir.
Les trois workspaces partagent l’identité et le domaine, mais leurs routes, rôles, scopes et navigations restent distincts. Cette séparation évite qu’une interface plus riche devienne un droit implicite.
6. Le portail client B2B
Catalogue, prix et autonomie dans le contexte du compte
Le portail gère les invitations, mots de passe, comptes historiques, CGV et contexte multi-compte. L’utilisateur choisit la société autorisée ; l’assortiment, le prix, les adresses, le panier, les commandes et les documents suivent ce périmètre.
Le catalogue combine distributions, catégories, marques, campagnes, nouveautés, variantes, images et fiches produit. Les prix proviennent des catégories tarifaires Odoo et les devises restent explicites. La disponibilité projetée protège les engagements existants.
Le client prépare un panier, relit les lignes et adresses, suit l’import, puis retrouve commandes, factures, avoirs, expéditions et assistance. Les états intermédiaires expliquent les traitements asynchrones.
L’étude de cas portail client, catalogue et tarifs personnalisés détaille cette expérience et les douleurs qu’elle résout.
7. Le cockpit commercial
Décider depuis le portefeuille, l’activité et les engagements
Le cockpit commercial transforme les objets du SI en poste de travail. Un compte réunit ses contacts, adresses, activité, commandes, livraisons, factures, avoirs et contraintes. Les commerciaux internes et externes travaillent dans leur portefeuille autorisé.
La prise de commande réutilise le catalogue et les règles transactionnelles. Les devis et commandes sont séparés, les statuts de livraison disposent d’une timeline et les documents financiers prolongent la lecture après la vente.
Les radars de clients à sauver, classements et analyses multi-périodes priorisent les comptes à examiner. Chaque indicateur garde un chemin vers la preuve et ne se présente pas comme une causalité automatique.
Le projet cockpit commercial et pilotage des comptes B2B montre comment cette densité devient une navigation et une liste d’actions.
8. La super-administration métier
Piloter les référentiels, la qualité et le run
L’administration couvre les clients, contacts, utilisateurs, identités, distributions, produits, catégories, marques, tags, prix, stock, kits, précommandes, fournisseurs, achats, ventes, documents, assistants et monitoring. Les menus ont été organisés par hubs fonctionnels.
Les équipes peuvent rafraîchir des objets depuis Odoo, contrôler les mappings, suivre les exports, lancer des reconstructions et consulter les preuves de stock. Les opérations sensibles sont protégées par rôle, CSRF, MFA ou confirmation selon l’impact.
La qualité des données ne se réduit pas à un score unique. Les vues exposent les incohérences, dates, sources et chemins de correction. Les admins peuvent comprendre si le problème vient du catalogue, d’un flux, d’une projection ou d’une donnée métier.
Le monitoring rend les files, activités API, synchronisations et scorecard accessibles dans le produit. Cette administration transforme la plateforme en système opérable, pas seulement en interfaces de vente.
9. Odoo, 25 flux et deux APIs métier
Le système circulatoire de la plateforme
Le catalogue d’intégration compte 25 flux Odoo autour du CRM, du catalogue, des prix, ventes, achats, expéditions, factures, avoirs et paiements. Les flux sont séparés par domaine, fréquence et risque plutôt que regroupés dans un import monolithique.
RabbitMQ, Messenger, workers, retries et crons exécutent les traitements longs. Les identités externes, fenêtres de date, devises et canaux sont conservés. Les replays contrôlés permettent de reprendre sans dupliquer ou mélanger le B2B et le B2C.
Deux familles d’API servent les parcours client et commercial externe. Leurs scopes, mappers, erreurs et contrats OpenAPI sont testés. L’API ne sérialise pas directement le modèle interne et ne donne pas plus de droits que le workspace web correspondant.
Le projet intégration Odoo, APIs et automatisation des flux documente les sources de vérité, mappings, idempotence, fraîcheur, observabilité et limites.
10. Catalogue, merchandising, prix et disponibilité
Transformer les référentiels en offre réellement vendable
La plateforme ne publie pas un export brut de produits. Elle résout les distributions actives, statuts, catégories, marques, variantes, images, campagnes, nouveautés, kits et précommandes. Les équipes peuvent piloter la visibilité et comprendre les exclusions.
Les catégories de prix Odoo donnent le tarif du compte. Les devises et relations de prix sont contrôlées ; une source absente ou périmée ne devient pas un prix par défaut silencieux. Le panier conserve le contexte nécessaire à la preuve.
La disponibilité ajoute les stocks, mouvements, expéditions, réservations et approvisionnements. Le client voit une synthèse ; le commercial et l’admin peuvent descendre vers les WH/OUT, snapshots et allocations.
Ce bloc relie les offres Dawap PIM et catalogue, Ciama PIM catalogue et portail B2B, sans que le projet ne soit réduit à l’une de ces pages commerciales.
11. Le cycle de commande B2B
Du panier modifiable à l’objet Odoo confirmé
Le panier valide le compte, la distribution, les variantes et les quantités. La relecture contrôle les adresses, prix, disponibilité et fraîcheur. Des réservations temporaires protègent la capacité pendant l’engagement.
Le plan peut découper les lignes en zones d’import. La soumission idempotente porte une identité stable, suit la progression et distingue demande reçue, import en cours, partie confirmée, échec et commande Odoo synchronisée.
Les mutations sont bloquées au bon moment ; les réservations expirent ou se libèrent selon le résultat ; les annulations passent par leurs propres règles. Le client et le commercial retrouvent ensuite la même commande adaptée à leur interface.
Le projet cycle de commande, du panier à la facture expose la machine à états, les cas limites et les preuves transactionnelles.
12. Factures, avoirs, paiements et documents
Prolonger la vente jusqu’à la preuve comptable
Les factures et avoirs synchronisés conservent leurs lignes, devises, canaux et identités Odoo. Les factures non postées ne sont pas publiées au client comme définitives. Les avoirs restent typés plutôt que noyés dans une table générique.
Les PDF stockés depuis Odoo sont réutilisés pour garantir la conformité du document. Les écritures et allocations de paiement sont protégées par des invariants sur le document, la devise et les montants.
Le cockpit commercial utilise ces données pour comprendre le règlement, le risque et le cash. Le portail donne au client ses documents dans le bon périmètre. Les APIs servent les mêmes lectures à leurs consommateurs autorisés.
Ce domaine prouve que la transformation ne s’arrête pas au taux de clic ou au panier. Elle relie la promesse commerciale à la preuve financière et au service après la vente.
13. Achats, fournisseurs et disponibilité projetée
Faire entrer l’amont dans la promesse client
Les fournisseurs, commandes d’achat, lignes et réceptions Odoo alimentent la vision de l’amont. Les dates et quantités attendues contribuent à la disponibilité future sans être confondues avec un stock déjà reçu.
Le moteur conserve les événements, snapshots et allocations. Le FIFO protège les demandes plus anciennes ; les réservations de panier réduisent la capacité ; les annulations et corrections de réception déclenchent une réconciliation.
Les kits utilisent la capacité de leurs composants. Les précommandes suivent leur date de première vente et leur activation. Les overrides de suivi procurement sont pilotés et historisés.
Le module produit rejoint les capacités Ciama achats et procurement et Ciama logistique et stock, nourries par ce retour terrain.
14. Préparation des livraisons
Une feuille de charge qui explique ses décisions
Le pipeline hebdomadaire organise les commandes, expéditions, capacités, arrivées, montants et tensions. Les vues séparent les canaux, regroupent les destinations et calculent les règles de franco. Les destinations non qualifiées possèdent un diagnostic.
Les propositions de réservation et réallocation sont reliées aux lignes exactes. Avant une action, le produit montre les bénéficiaires et les victimes potentielles. Les écritures Odoo à impact restent confirmées par un humain.
Les expéditions préparées conservent un historique. Le tracking transporteur peut être rafraîchi dans le cadre prévu. Les timelines alimentent les clients et commerciaux sans leur exposer tout le cockpit opérationnel.
L’étude de cas achats, stock disponible et préparation des livraisons détaille cette chaîne et sa limite human-in-the-loop.
15. Six assistants IA reliés au métier
Accélérer l’accès à la preuve sans créer une nouvelle vérité
Six assistants sont réellement implémentés : Global Assistant pour l’orientation, Data Query pour les lectures bornées, Company Checker pour la qualification, Employee Brain pour la connaissance RAG, AI Alert pour les signaux et Dashboard Copilot pour l’interprétation.
Le RAG indexe des pages fonctionnelles, guides, schémas et éléments de catalogue avec des identités renouvelables. Les requêtes de données utilisent des spécifications strictes et des opérations autorisées ; le modèle n’obtient pas un accès SQL libre.
Les assistants respectent rôles et scopes, disposent de traces et de runs asynchrones identifiés. Les actions sensibles sont préparées puis confirmées via les cas d’usage normaux. Une indisponibilité IA ne doit pas empêcher l’application de fonctionner.
Le projet assistants IA connectés aux connaissances et données métier explique aussi pourquoi les sept autres entrées exploratoires du catalogue ne sont pas revendiquées comme livrées.
16. Sécurité, identité et gouvernance des actions
Protéger les comptes, les scopes et les écritures
Les rôles distinguent client B2B, commercial, commercial externe et administration. Les ressources vérifient le compte ou portefeuille autorisé côté serveur. Les tests anti-IDOR ciblent les accès horizontaux et les tokens ne peuvent pas changer de scope pendant un refresh.
CSRF, MFA, confirmations, rate limiting, audit et redaction protègent les actions et les traces. L’impersonation est encadrée ; les resets MFA et politiques d’identité sont couverts ; les espaces d’écriture sensibles restent séparés.
La supply chain produit des preuves sur les dépendances, images et SBOM. La CSP est évaluée en report-only, mais l’enforcement complet de production n’est pas encore déclaré acquis. Les secrets restent fournis par environnement.
Cette transparence est une décision de gouvernance : publier 97/100 en sécurité avec les points manquants apporte plus de confiance qu’un “secure by design” impossible à vérifier.
17. Architecture, tests, CI et run
Le socle qui permet à tout le reste de continuer à évoluer
La stack Symfony 8, PHP 8.4, MySQL, Redis, RabbitMQ, Docker et Nginx est organisée par domaines, ports et adaptateurs. Les contrôleurs restent proches de la présentation et les services de domaine portent les invariants.
Le rapport de référence des quatre suites totalise 22 991 tests et 239 326 assertions sans failure, error ni skipped. La campagne PCOV canonique couvre 199 892 statements sur 199 892 et ses seuils restent ratchetés à 100 dans douze univers.
La CI utilise sept shards, compare les contrats, contrôle l’architecture, la maintenabilité, la sécurité et construit les images. Aucun fichier PHP de production n’atteint 650 lignes ; le maximum est de 649. La scorecard stricte reste à 99/100.
Le projet industrialisation d’une plateforme B2B critique explique les méthodes et les dettes restantes, notamment le recovery drill non exécuté.
18. Une chaîne de valeur continue, de l’offre au run
Comprendre comment les capacités se renforcent au lieu de s’empiler
Le catalogue ne crée de valeur que si l’offre, le prix et la disponibilité sont résolus pour le bon compte. Cette promesse doit ensuite survivre au panier, à la réservation, à l’import Odoo, à l’expédition et au document financier. Chaque maillon dépend du précédent, mais conserve son propre état et sa propre preuve.
Le cockpit commercial traverse cette chaîne dans le sens de la relation : comprendre le compte, préparer une vente, suivre l’engagement et intervenir lorsqu’un signal se dégrade. L’administration la traverse dans le sens du run : maintenir les référentiels, diagnostiquer les flux, reconstruire une projection et confirmer les actions à risque.
Les assistants IA ajoutent une couche d’accès à cette complexité. Ils orientent, interrogent ou contextualisent, mais retournent vers les objets déterministes. L’industrialisation protège enfin l’ensemble par les contrats, tests, scopes, files, déploiements et procédures de reprise.
Cette continuité explique pourquoi le projet ne peut pas être résumé à un site connecté à Odoo. La valeur vient de la capacité à faire circuler une intention commerciale jusqu’à son exécution, puis à rendre chaque transition observable et récupérable.
Compte, catalogue, tarif et disponibilité
Panier, réservation et commande Odoo
Achat, allocation, expédition et tracking
Facture, avoir, paiement et historique
Cockpit, IA, monitoring et scorecard
Ce qui se passe lorsqu’un maillon échoue
Une source de prix absente bloque l’engagement au lieu de produire un tarif par défaut. Un snapshot trop ancien exige une reconstruction. Une réponse Odoo perdue conserve la transaction dans un état réconciliable. Une expédition partielle reste partielle dans la lecture commerciale.
Ces comportements défensifs donnent au système une propriété essentielle : l’échec reste situé. Il ne se transforme pas silencieusement en succès dans l’interface suivante et peut être repris depuis le maillon qui possède réellement la responsabilité.
Ce qui reste partagé malgré la spécialisation
L’identité du compte, la distribution, la devise, les références Odoo, les scopes et les états de traitement forment le langage commun. Les interfaces peuvent simplifier leur présentation, mais elles ne redéfinissent pas ces invariants.
Cette base permet d’ajouter un nouveau canal, une analyse ou un assistant sans dupliquer toute la chaîne. La nouvelle capacité consomme des ports et des contrats existants, puis apporte ses propres preuves et garde-fous.
19. Résultats obtenus et limites assumées
Une transformation prouvée par le produit, pas embellie par des KPI inventés
Le premier résultat est la continuité. Un compte, un produit, un prix, une commande et une livraison ne vivent plus comme cinq sujets séparés. Les workspaces donnent des lectures adaptées tout en s’appuyant sur les mêmes identités et règles.
Le deuxième résultat est l’autonomie contrôlée. Le client accède à son offre et ses documents ; le commercial pilote son portefeuille ; l’administration observe et reprend ; les assistants accélèrent la recherche. Les actions à fort impact gardent une validation humaine.
Le troisième résultat est la capacité d’évolution. Les domaines, tests, contrats, files, scorecard et runbooks réduisent le coût de changement et donnent une preuve reproductible. La plateforme peut accueillir de nouveaux parcours sans repartir d’un socle opaque.
Les limites restent publiées : aucun chiffre de revenu ou de conversion n’est attribué sans mesure client, sept concepts IA ne sont pas implémentés, l’API client ne possède pas un raccourci générique panier-vers-commande, la CSP production reste à finaliser et le recovery drill doit être exécuté.
Ce que l’autonomie change sans supprimer le contrôle
Le client peut trouver son offre, préparer sa demande et retrouver ses documents sans solliciter une équipe pour chaque étape. Cette autonomie ne vient pas d’un accès plus large : elle vient d’un contexte mieux résolu, de statuts plus honnêtes et de chemins de correction prévus.
Les équipes récupèrent du temps sans perdre la capacité d’intervenir. Le commercial voit les engagements, l’administration retrouve les flux et les opérations valident les arbitrages qui changent réellement une promesse.
Ce que la plateforme permet désormais d’améliorer
Les nouveaux besoins peuvent partir d’un domaine et d’un contrat existants plutôt que d’un export supplémentaire. Une évolution de disponibilité bénéficie des événements et reconstructions ; un nouveau canal réutilise les scopes et le catalogue effectif ; un assistant reçoit des sources déjà gouvernées.
Cette capacité d’évolution est le résultat le plus durable. Elle ne garantit pas qu’une future fonctionnalité sera simple, mais elle rend son impact visible, testable et déployable dans un système dont les frontières sont connues.
20. Choisir le bon point d’entrée selon votre enjeu
Commencer par la douleur la plus proche, puis suivre ses dépendances
Si la priorité est l’autonomie des comptes, le projet portail client B2B montre comment assortiment, tarif, disponibilité et documents deviennent une expérience contextualisée. Pour un enjeu d’efficacité commerciale, le cockpit commercial part du portefeuille et des décisions quotidiennes.
Si le risque se situe entre les systèmes, l’intégration Odoo et ses 25 flux expose l’orchestration, tandis que le cycle de commande approfondit l’idempotence, les réservations et la reprise transactionnelle.
Pour une tension sur la promesse logistique, le projet achats, disponibilité et livraisons relie l’amont fournisseur aux allocations. Les six assistants IA traitent l’accès à la connaissance ; l’industrialisation apporte les preuves de qualité et de run.
La page produit Ciama B2B présente enfin les capacités produit nourries par cette expérience terrain, sans faire passer le développement sur mesure 1UP pour un déploiement standard de Ciama.
21. Conclusion : une activité B2B devenue un produit pilotable
Une seule architecture de valeur, de l’offre au run
La transformation de 1UP Distribution relie désormais des problèmes qui étaient trop coûteux à traiter séparément : vendre avec le bon contexte, synchroniser sans diverger, engager sans doubler, approvisionner sans surpromettre, livrer avec une preuve et faire évoluer sans perdre le contrôle.
Le portail, le cockpit, l’administration, Odoo, la logistique et l’IA ne forment pas une collection de modules. Ils partagent des identités, un domaine, des contrats et une capacité de reprise. C’est cette continuité qui transforme une accumulation fonctionnelle en produit opérationnel.
Pour construire une trajectoire comparable, notre offre d’application web connectée à un ERP ou CRM constitue le point d’entrée naturel. Le travail mené avec 1UP montre jusqu’où Dawap peut aller lorsque produit, intégration, données, IA et run sont traités comme un même système.
