Le projet en un coup d’œil
Activité, contacts, devis, commandes, expéditions, factures et risque commercial n’étaient pas réunis dans un contexte actionnable.
Dawap a regroupé le CRM opérationnel, la prise de commande, le suivi du pipe, la finance et les analyses commerciales.
Chaque commercial travaille dans son périmètre et passe du signal à l’action sans reconstruire manuellement le dossier client.
Un commercial B2B ne manque généralement pas de données. Il manque d’une lecture fiable au moment où il doit agir. Un client peut avoir commandé hier, attendre une livraison, dépasser une limite de crédit, ne plus acheter une gamme ou ne pas répondre à une relance. Si ces signaux restent répartis dans l’ERP, les emails et plusieurs exports, le pilotage dépend de la mémoire de chacun.
Le défi n’était donc pas d’ajouter un écran de plus, mais de reconstituer une continuité de décision : partir d’un signal, comprendre ce qui l’explique, vérifier le périmètre concerné et agir sans perdre le contexte. La réorganisation du workspace, le radar des clients à sauver, les flux Odoo B2B et l’accès mobile ont été pensés comme les pièces d’un même poste de travail.
Dawap a construit ce produit comme un back-office métier sur mesure, et non comme un tableau de bord décoratif. Chaque indicateur doit mener vers un compte, une commande, une facture, une action ou une explication ; chaque action doit respecter les rôles et laisser une trace.
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. Le quotidien commercial chez 1UP Distribution
Un portefeuille B2B où la vente ne s’arrête pas à la commande
Les équipes commerciales de 1UP Distribution gèrent des comptes professionnels, leurs contacts, leurs adresses, leurs conditions de vente et un historique qui traverse le catalogue, la commande, la livraison et la finance. La qualité de la relation dépend autant de la prochaine opportunité que du respect des engagements déjà pris.
L’ERP contient une partie essentielle de cette vérité, mais sa structure n’est pas toujours la meilleure interface pour une journée commerciale. À l’inverse, un CRM isolé du réel peut présenter une belle fiche client sans connaître un retard d’expédition, un avoir ou une commande en attente. Le besoin était de relier ces deux mondes.
Le cockpit devait également servir plusieurs profils : commerciaux internes, commerciaux externes, responsables et administrateurs. Les écrans, les données disponibles et les actions autorisées varient selon le portefeuille. Cette contrainte de portée a été intégrée dans l’architecture, les contrôleurs, les requêtes et les APIs.
2. Construire le cockpit autour des décisions
Partir des questions terrain plutôt que d’une liste de graphiques
Le cadrage a recensé les décisions récurrentes : quel client rappeler, quel compte semble décrocher, quelle commande doit être surveillée, quel devis mérite une relance, quelle livraison menace la relation et quelle situation financière bloque une nouvelle vente. Chaque question a été reliée aux données nécessaires et à l’action suivante.
Le delivery a alterné des lots de fond — portée des comptes, modèles de vente, synchronisation Odoo, agrégats — et des lots d’usage — navigation, fiche client, radar, commande, pipeline, reporting. Le backlog Jira a priorisé les sujets capables de sécuriser une décision commerciale complète avant d’élargir le cockpit. Cette progression empêche de construire des interfaces plus vite que les preuves qu’elles doivent afficher.
Les démonstrations, retours terrain et tests ont fait évoluer la densité des tables, les filtres, les états vides, les performances et le vocabulaire. Sur un cockpit, un libellé ambigu ou un filtre caché peut coûter davantage qu’un défaut esthétique : il fait prendre une décision sur le mauvais périmètre.
3. Les douleurs commerciales à résoudre
Trop d’information, pas assez de continuité
La première douleur était la fragmentation. Pour comprendre un compte, il fallait rapprocher l’identité du client, ses contacts, ses commandes, ses documents financiers, ses livraisons et parfois des notes ou exports parallèles. Le temps passé à chercher réduisait le temps disponible pour décider et entretenir la relation.
La deuxième douleur était la portée. Une interface commune ne peut pas signifier un accès commun à toutes les données. Un commercial externe ne doit pas consulter un portefeuille qui ne lui appartient pas ; une API mobile ne doit pas élargir les droits de l’interface web ; un filtre ne doit pas être la seule barrière entre deux périmètres.
La troisième douleur était la hiérarchie. Une liste de centaines de comptes ou de commandes ne dit pas où commencer. Le produit devait faire émerger les variations, retards, risques, opportunités et anomalies qui justifient une action aujourd’hui.
Un KPI sans lien vers la preuve et sans action possible reste un objet de présentation. Le cockpit a été conçu pour permettre de descendre du signal vers les lignes, les documents et le compte concerné.
Quand la mémoire individuelle devient une dépendance du système
Dans une organisation B2B, une grande partie du contexte peut vivre dans la tête du commercial : habitudes d’achat, commande atypique, tolérance à un retard, promesse formulée au téléphone. Cette connaissance reste précieuse, mais elle devient dangereuse lorsqu’elle est le seul moyen de relier les faits. Une absence, un changement de portefeuille ou une croissance rapide suffit alors à casser la continuité.
Le cockpit ne cherche pas à normaliser toute la relation humaine. Il sécurise son socle factuel : quels objets existent, quel événement s’est produit, quel montant est ouvert, quelle expédition est attendue et qui est autorisé à intervenir. Le commercial conserve l’interprétation ; le produit retire la collecte manuelle qui la fragilisait.
Pourquoi un tableau de bord générique aurait échoué
Une solution de reporting aurait pu agréger les ventes et produire des graphiques. Elle n’aurait pas résolu la prise de commande, l’ouverture d’un document, la portée d’un commercial externe ou la compréhension d’une livraison partielle. Or la valeur apparaît précisément dans le passage entre lecture et action.
Dawap a donc traité le cockpit comme une application métier transactionnelle : les indicateurs constituent des portes d’entrée, les pages de détail exposent la preuve et les actions réutilisent les mêmes règles de domaine que le portail et les flux Odoo.
4. Un workspace commercial organisé par métier
Une navigation qui suit la journée, pas la structure technique
Le workspace regroupe le tableau de bord, les clients, les contacts, le catalogue, la prise de commande, les devis, les commandes, les livraisons, les factures, les avoirs, le pipeline et les analyses. La navigation a été réorganisée pour distinguer vente, relation client, exécution et reporting.
Les vues conservent les filtres utiles et limitent les données au portefeuille autorisé. Les écrans denses ont été retravaillés pour réduire les colonnes redondantes, rendre les actions visibles et garder un comportement utilisable sur des formats plus étroits. Les états vides expliquent si le problème vient d’un filtre, d’un périmètre ou d’une absence réelle de données.
La recherche transverse aide à retrouver un compte, un contact, une référence ou une commande sans connaître le module exact. Elle respecte les mêmes règles d’accès que la navigation. L’expérience devient plus rapide sans créer un raccourci autour de la sécurité.
Ce type de poste de travail illustre notre approche de l’application métier sur mesure : l’architecture de l’information est dictée par les tâches, les risques et les rôles réels.
5. Une vision CRM reliée à l’activité réelle
Le compte client comme point de convergence
La fiche client rassemble l’identité, les contacts, les utilisateurs, les adresses, les conditions, l’activité et les objets de vente autorisés. Les comptes Odoo sont synchronisés et peuvent être créés dans le cadre prévu, avec des contrôles de mapping et de déduplication.
Les contacts sont filtrés par compte et rendus plus lisibles dans des tables compactes. Les choix d’adresse reviennent au bon client et les liens entre contact, utilisateur et société sont contrôlés. Une erreur de rattachement pourrait exposer un document ou créer une commande au mauvais endroit ; elle est donc traitée comme une règle de domaine.
Le cockpit ne cherche pas à remplacer l’ERP par une copie locale. Il prépare une lecture commerciale et des actions encadrées autour de la source de vérité. Les données locales servent l’expérience, les agrégats et la résilience, tandis que les identifiants et statuts externes permettent la réconciliation.
L’enjeu de répartition des données entre outils est détaillé dans l’article intégration CRM et portail client : quelle donnée doit vivre où.
6. Prise de commande assistée
Commander pour un client sans contourner les règles du portail
Le commercial peut préparer une commande dans un parcours dédié : sélectionner le compte, parcourir le catalogue accessible, choisir les variantes et quantités, vérifier la disponibilité, renseigner les adresses et relire le panier. Le produit réutilise les règles centrales plutôt que de créer un second moteur de vente réservé aux équipes.
Le contexte commercial ajoute toutefois ses propres besoins : recherche plus rapide, reprise de panier, visibilité sur les informations utiles au compte et suivi de l’import. Les flux externes disposent aussi de contrats spécifiques, notamment pour l’accès mobile et les intégrations commerciales.
La commande est soumise au mécanisme d’import Odoo et à ses états. Les références, zones et lignes restent identifiables pendant la progression. Une erreur n’est pas transformée en succès local ; elle devient une situation à comprendre, corriger ou rejouer.
Le projet cycle de commande B2B, du panier à la facture documente en profondeur ce moteur transactionnel commun.
7. Pipeline de commande et engagements de livraison
Suivre ce qui a été promis après la vente
Le pipeline rapproche les commandes, leurs lignes, les engagements, les expéditions et les dates utiles. Les commerciaux peuvent lire une progression au lieu de s’arrêter au statut “confirmé”. Une timeline aide à comprendre les jalons disponibles sans obliger l’utilisateur à interpréter les objets techniques d’Odoo.
Les filtres séparent les canaux et protègent le périmètre B2B. Les anomalies de destination, les commandes partielles, les reliquats et les décalages d’expédition deviennent visibles. Cette lecture est essentielle pour prévenir un client avant qu’il ne transforme un retard en incident de relation.
Les détails logistiques les plus complexes restent dans le cockpit de livraison spécialisé. Le commercial reçoit la synthèse nécessaire pour communiquer et prioriser, tandis que les équipes opérations conservent les outils de diagnostic, de réservation et d’arbitrage.
Cette séparation des responsabilités empêche de surcharger l’espace commercial tout en gardant un lien direct vers la preuve. Le projet stock et préparation des livraisons présente la profondeur de ce second niveau.
8. Factures, avoirs, paiements et recouvrement
Inclure la réalité financière dans la relation client
Les factures et avoirs disposent de vues distinctes, avec leurs lignes, devises, documents et états. Les règlements et allocations issus du SI peuvent être rapprochés afin de comprendre ce qui est payé, partiellement réglé ou encore ouvert. Les PDF Odoo stockés sont réutilisés plutôt que régénérés de manière divergente.
Le cockpit peut faire émerger les comptes sous contrainte de crédit et les éléments utiles au suivi du cash. Cette information n’est pas utilisée comme un simple badge rouge : elle influence les actions disponibles et la conversation à avoir avec le client.
Les invariants financiers protègent les montants, les devises et les allocations. Une écriture incohérente doit être rejetée ou signalée, pas arrondie silencieusement pour embellir un total. La finance reste un domaine où la preuve l’emporte sur la commodité d’affichage.
Pour les entreprises qui rencontrent ce besoin, notre page intégration finance et comptabilité explique le cadrage ; le cockpit 1UP montre la traduction concrète dans un outil quotidien.
9. Radars de comptes à sauver et priorisation
Transformer les signaux faibles en liste de travail
Le radar des clients à sauver analyse les évolutions d’activité et restitue des comptes qui méritent une attention. La logique a été optimisée et enrichie pour éviter qu’un classement coûteux ou trop générique ne ralentisse le cockpit. Le commercial retrouve les éléments qui expliquent la priorité.
Les signaux peuvent croiser une baisse de commande, une absence d’activité récente, une situation de livraison ou un contexte de compte. Le produit ne présente pas ces résultats comme une vérité prédictive. Il les propose comme une aide à la revue, avec la possibilité de revenir aux données observées.
Des classements et analyses complètent cette lecture : évolution des ventes, meilleurs clients, familles de produits, commerciaux, canaux et périodes. La valeur vient de la cohérence des définitions et de la possibilité de filtrer, pas du nombre de graphiques.
Ce choix prépare aussi les usages IA sans déléguer la décision. Un assistant peut résumer ou orienter ; la liste d’actions reste fondée sur des indicateurs calculés, vérifiables et compris par l’équipe.
Baisse, retard, impayé ou inactivité
Score et portefeuille autorisé
Compte, lignes et documents sources
Relance, commande ou arbitrage
Événement et résultat retrouvables
10. Reporting commercial multi-périodes
Comparer sans mélanger les périmètres
Le reporting agrège les ventes par périodes et dimensions commerciales. Des filtres permettent d’examiner l’évolution, les écarts, les canaux et les portefeuilles. Les calculs ont été isolés et testés pour éviter qu’une même notion change selon le graphique ou le point d’entrée.
Les tableaux de bord distinguent la vue d’ensemble des détails. Un responsable peut lire la tendance, puis descendre vers la commande, le client ou la ligne qui contribue au résultat. Les périodes explicites sont bornées pour empêcher des rafraîchissements Odoo disproportionnés.
Les exports de catalogue et de suivi sont exécutés de manière asynchrone lorsque le volume le demande. Leur progression et leurs échecs sont suivis. L’utilisateur ne dépend pas d’une requête HTTP longue ni d’un fichier qui semble ne jamais arriver.
Cette discipline de reporting rapproche le cockpit d’une démarche de data intelligence décisionnelle, tout en conservant des indicateurs déterministes pour les décisions récurrentes.
11. Accès mobile et API commerciale
Étendre le cockpit sans étendre les droits
Une API dédiée aux usages commerciaux externes expose les ressources nécessaires dans un contrat maîtrisé. Elle couvre notamment le catalogue, les catégories, les paniers, les commandes, les factures et les informations autorisées. Les schémas ont été simplifiés et documentés pour ne pas recopier les modèles internes.
Les tokens et refresh tokens portent une portée explicite. Les tests refusent les échanges de scope et les accès croisés. Cette protection est essentielle : une application mobile ou un client API ne doit pas devenir une voie moins contrôlée vers les données B2B.
Les réponses sont conçues pour les usages attendus et les erreurs métier sont documentées. Une ressource absente du portefeuille ne devient pas distinguable d’une ressource inaccessible d’une manière qui faciliterait l’énumération.
Le cockpit gagne ainsi en mobilité sans dupliquer le domaine. Web et API reposent sur les mêmes règles applicatives, puis adaptent leur présentation au canal.
12. Périmètres, rôles et traçabilité
La sécurité comme partie du modèle commercial
Les contrôles de rôle séparent clients, commerciaux, commerciaux externes et administrateurs. La portée du portefeuille est vérifiée au niveau des lectures et des actions. Les contrôleurs ne se contentent pas de cacher un lien de navigation ; les dépôts et cas d’usage reçoivent le périmètre autorisé.
Les actions sensibles nécessitent les protections adaptées : CSRF, confirmation, journalisation et parfois MFA. Les lancements manuels de flux Odoo sont limités aux comptes B2B concernés, et les replays demandent une intention explicite.
Les événements de connexion et traces d’activité alimentent le diagnostic. Les données sensibles sont redactées dans les logs lorsque nécessaire. Une trace utile doit permettre de comprendre une action sans devenir une fuite de données.
L’ensemble est testé contre les accès IDOR et les changements de scope. Cette sécurité est une condition de confiance pour ouvrir un cockpit riche à plusieurs populations.
13. Qualité, performance et exploitation
Un cockpit rapide malgré des lectures transverses
Les requêtes de radar, de recherche, d’analyse et de listes ont été revues pour éviter les parcours coûteux. Les filtres par défaut, les agrégats prévus et les lectures spécialisées réduisent la quantité de données chargée. Les scripts des dashboards ont été découpés pour rester maintenables.
Les tests couvrent les contrats de tableaux de bord, les sorties API, les filtres, les périmètres et les comportements mobiles. Les cas de données absentes ou partielles sont autant travaillés que les écrans remplis, car ce sont eux qui révèlent souvent les mauvaises hypothèses.
La supervision des tâches asynchrones, exports et synchronisations permet d’expliquer un retard sans ouvrir immédiatement le code. Les équipes peuvent distinguer une donnée non encore rafraîchie, un flux échoué et un véritable état métier.
Ces éléments s’appuient sur le même socle d’industrialisation que le portail client. Le projet plateforme B2B critique en fournit les preuves transverses.
14. Résultats obtenus et limites
Un poste de travail, pas une promesse de vente automatique
Le cockpit donne aux commerciaux une continuité entre connaissance du compte, prise de commande, suivi de livraison, finance et reporting. Il réduit les ruptures de contexte et fournit des chemins directs entre un signal et sa preuve.
Les responsables gagnent une lecture partagée des définitions et des portefeuilles. Les commerciaux externes disposent d’un accès adapté sans élargissement silencieux de leur périmètre. Les équipes techniques disposent de contrats et de traces pour diagnostiquer les flux.
Le produit n’automatise pas la qualité d’une relation commerciale. Il ne remplace ni l’interprétation du terrain, ni l’arbitrage d’une limite de crédit, ni une conversation avec un client. Il rend ces décisions mieux informées et moins dépendantes de recherches dispersées.
La prochaine couche de l’histoire se trouve dans le projet intégration Odoo, APIs et automatisation des flux B2B, qui montre comment les données arrivent et restent récupérables.
Ce qui change dans une revue de portefeuille
Une revue peut commencer par les comptes qui exigent une attention, puis descendre vers les événements qui justifient cette priorité. Le responsable et le commercial discutent ainsi du même périmètre, avec des définitions communes et des liens directs vers les objets concernés.
Cette continuité réduit les débats sur la provenance d’un chiffre et concentre l’échange sur la décision : contacter, attendre, débloquer, corriger ou escalader. C’est un gain de qualité opérationnelle mesurable dans le fonctionnement du produit, sans prétendre attribuer artificiellement un revenu à l’interface.
La limite volontaire : recommander sans décider
Un compte qui commande moins n’est pas nécessairement un compte perdu ; un retard n’a pas le même impact selon le client ; un signal financier peut demander une lecture contractuelle. Le cockpit conserve donc les explications et les sources au premier plan.
Cette limite protège l’équipe contre une automatisation opaque. Les règles peuvent évoluer, les assistants IA peuvent enrichir la préparation, mais la décision commerciale reste attribuable à une personne qui dispose des éléments pour la défendre.
15. Conclusion : donner aux commerciaux un système de décision
Relier la relation client aux faits opérationnels
Ce cockpit commercial illustre une différence importante : un bon back-office ne se mesure pas à la quantité de données qu’il affiche, mais à la qualité des décisions qu’il permet de prendre. Le périmètre, la preuve et l’action doivent rester liés.
Pour 1UP Distribution, Dawap a réuni la vente, le CRM opérationnel, le pipeline, la finance et les radars dans un produit cohérent. Les interfaces restent proches du quotidien, tandis que l’architecture protège les droits, les contrats et les reprises.
Notre offre de back-office métier sur mesure constitue le point d’entrée pour une problématique comparable. Le travail mené avec 1UP en montre l’aboutissement dans un environnement B2B réel.
