Le projet en un coup d’œil
Catalogue, tarifs, commandes, documents, logistique et accès utilisateurs partagent des données critiques : une modification locale peut avoir un effet bien au-delà de son écran.
Dawap a séparé les responsabilités, verrouillé les contrats sensibles et organisé les tests, les déploiements, la supervision et les reprises.
Les évolutions peuvent avancer par lots tandis que les commandes, les droits, les sessions et les échanges avec Odoo restent protégés.
Une plateforme B2B devient critique dès qu’elle porte les prix, les commandes, les documents, les réservations de stock et les décisions des équipes. Une anomalie locale peut alors retarder une vente, afficher une information au mauvais compte ou interrompre une opération logistique. Ralentir toutes les évolutions ne résout pas ce risque : il faut construire une manière fiable de changer.
C’est le fil conducteur du travail mené pour 1UP Distribution. Au fur et à mesure que le portail client, le cockpit commercial, l’administration, la logistique et les API se sont enrichis, Dawap a consolidé ce qui les relie : les règles métier, les droits, les contrats de données, les traitements de fond et la chaîne de mise en production.
Cette étude montre une refonte de logiciel métier conduite sans grand soir. Chaque lot retire un risque précis, prouve le comportement attendu et prépare le lot suivant. Le résultat n’est pas seulement un socle plus propre : c’est une plateforme que 1UP peut continuer à faire évoluer sans opposer nouveauté et continuité de service.
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 grossiste B2B piloté par ses flux
Catalogue, vente, approvisionnement et logistique se rencontrent dans la même plateforme
1UP Distribution commercialise plusieurs marques et familles de produits auprès de comptes professionnels. Ses clients consultent un catalogue contextualisé, leurs tarifs, leurs commandes et leurs documents. Les équipes commerciales, administratives et logistiques utilisent de leur côté les mêmes données pour vendre, arbitrer, préparer et suivre.
La plateforme relie ces usages à Odoo, à la recherche catalogue, aux traitements asynchrones et à deux API métier. Le prix affiché, le stock vendable, le statut d’une commande ou le document proposé dépendent donc à la fois du compte connecté, de l’état du produit et de la synchronisation des systèmes.
Cette proximité entre commerce et technique explique l’enjeu d’industrialisation. Déployer une nouvelle version, reprendre un flux ou faire évoluer une API ne doit pas effacer une session, dupliquer une commande ni ouvrir un périmètre de données. L’exploitation fait donc partie du produit, au même titre que les écrans.
2. Des lots courts autour d’un risque concret
Faire avancer le produit et sa capacité d’exploitation au même rythme
L’historique du produit montre une progression continue depuis le premier catalogue connecté : recherche, comptes clients, paniers, commandes, documents, disponibilité, espaces internes, API, logistique puis continuité des déploiements. Chaque extension a été accompagnée par le renforcement de la zone qu’elle rendait plus sensible.
Le lot commence par nommer le comportement qui ne doit pas casser : un prix propre au compte, une commande créée une seule fois, un document réservé au bon client, une session conservée pendant une mise en ligne. L’architecture et le test viennent ensuite protéger cette règle plutôt qu’ajouter une abstraction sans effet métier.
Les changements passent par une sandbox avant la production. Les sujets les plus sensibles disposent de contrôles avant ouverture, d’une procédure de retour à l’image précédente et de gestes de reprise bornés. Cette logique de lots permet de continuer à livrer tout en renforçant progressivement les frontières les plus coûteuses en cas d’incident.
3. Grandir sans fragiliser les ventes déjà en cours
Les risques les plus sérieux se trouvent entre deux fonctions
Le premier risque venait de la propagation. Une règle de disponibilité modifiée pour le portail pouvait aussi toucher une proposition commerciale, une réservation ou la préparation d’une livraison. Sans responsabilité clairement placée, deux écrans finissent par expliquer différemment la même situation.
Le deuxième risque concernait les frontières externes. Odoo peut répondre tardivement, une file peut rejouer un message et une API peut recevoir une combinaison inattendue. Une intégration robuste doit savoir refuser, attendre ou reprendre sans transformer l’incident en doublon commercial.
Le troisième risque apparaissait au moment de livrer. Quand plusieurs profils travaillent dans la plateforme, une mise à jour ne doit pas les déconnecter sans raison ni rouvrir le trafic avant que l’application, les traitements de fond et les données soient prêts.
Chaque protection doit se rattacher à une capacité concrète : vendre au bon prix, commander une seule fois, voir uniquement son compte, retrouver sa session ou reprendre un traitement interrompu.
Une fonction peut être correcte seule et dangereuse dans l’ensemble
Un nouveau champ dans le panier concerne l’interface, mais aussi l’API, le stockage, la transmission vers Odoo et la consultation par les équipes internes. Une modification du stock concerne le catalogue, mais aussi la promesse faite au client et le plan de livraison.
Dawap a donc traité les contrats entre domaines comme des produits à part entière. Les données minimales, les erreurs autorisées, les droits et les reprises sont explicités afin qu’une évolution reste compatible avec le reste du parcours.
La preuve doit suivre le risque, pas le nombre de lignes
Un scénario nominal ne suffit pas à protéger une activité B2B. Les cas coûteux sont souvent une réponse partielle, un nouvel essai après interruption, une donnée devenue indisponible ou un utilisateur qui tente d’agir hors de son compte.
Les contrôles ont été organisés autour de ces effets. Le comportement attendu est vérifié au niveau de la règle, puis de l’intégration et enfin du parcours HTTP lorsque l’enchaînement complet porte le risque.
4. Une architecture alignée sur les responsabilités métier
Faire évoluer une zone sans réécrire toutes les autres
Le produit sépare le CRM, le catalogue, la vente, les achats, le stock, la livraison, la finance, l’identité, les intégrations et la supervision. Chaque domaine porte ses règles et expose des interfaces précises aux autres parties de la plateforme.
Odoo, MySQL, les messages asynchrones, les fichiers et les services externes restent des moyens d’accès. Une règle de réservation ou d’autorisation peut ainsi être comprise et vérifiée sans dépendre de tous les systèmes à la fois.
Cette séparation rend les changements plus lisibles. Ajouter un filtre logistique, un commentaire de commande ou une nouvelle lecture fournisseur ne demande pas de contourner le cœur du produit. La fonctionnalité s’insère dans un contrat existant ou fait évoluer ce contrat explicitement.
Le projet illustre ainsi ce que doit devenir une application web métier lorsqu’elle prend de l’ampleur : des usages riches pour les équipes, mais des responsabilités assez nettes pour rester modifiables.
5. Reprendre progressivement les zones les plus risquées
La maintenabilité se mesure à la facilité de changer sans effet de bord
La reprise n’a pas cherché à réécrire la plateforme en une fois. Les concentrations de responsabilité ont été traitées lorsqu’elles rendaient une fonction lente à modifier, difficile à tester ou trop risquée à mettre en ligne.
Les calculs de disponibilité, la préparation des livraisons, les catalogues, les documents de vente, les lectures Odoo et les assistants ont été découpés selon leurs usages. Une correction peut alors cibler le service concerné sans rouvrir tout le parcours.
Le même travail a été mené dans les interfaces. Les tableaux logistiques, les vues commerciales et les formulaires complexes ont été séparés en composants qui portent une responsabilité identifiable. Les règles de vente ne sont pas abandonnées à un script d’écran.
Pour 1UP, le gain est une feuille de route moins prisonnière de l’existant. Une fonction utile peut être ajoutée en s’appuyant sur des frontières connues, tandis qu’une zone encore fragile peut être reprise sans imposer un arrêt global du produit.
6. Prouver les parcours qui portent une commande ou un droit
Tester l’effet métier avant de compter les scénarios
Les contrôles unitaires isolent les calculs de stock, d’allocation, de prix et de validation. Les contrôles d’intégration vérifient les accès aux données, les messages et les échanges avec Odoo. Les parcours applicatifs rejouent enfin les actions visibles depuis les quatre espaces métier et les API.
La priorité va aux invariants qui protègent l’activité : une commande confirmée ne doit pas être recréée, un contact ne doit pas sortir de son compte, une réservation ne doit pas survivre dans un état contradictoire et un document officiel doit rester rattaché à la bonne vente.
Chaque anomalie corrigée laisse un scénario de non-régression. C’est notamment le cas sur les périmètres utilisateurs, les commentaires de panier, les contributions au potentiel de livraison, les PDF officiels et les traitements qui peuvent être rejoués.
La preuve ne s’arrête pas à une exécution locale. Les fonctions qui dépendent des images, des files, des sessions ou du réseau disposent aussi de contrôles adaptés à la sandbox et au processus de livraison.
7. Tester aussi l’absence, l’interruption et la reprise
Les incidents se cachent rarement dans le parcours idéal
Un import peut recevoir une réponse incomplète. Un document peut ne pas encore être disponible. Une file peut rendre un message après le déploiement d’une nouvelle version. Une session peut expirer pendant une maintenance. Ces situations sont traitées comme des parcours à concevoir, pas comme des exceptions invisibles.
Les reprises utilisent des identités stables et des états explicites. Lorsqu’un traitement est relancé, il retrouve ce qui a déjà été fait et limite ses effets au périmètre attendu. Une erreur n’est pas transformée en succès uniquement pour nettoyer un tableau de bord.
Les données manquantes disposent de comportements différents selon leur portée. Une image peut accepter un visuel de remplacement ; un prix, un droit ou une commande ne peut pas accepter une valeur inventée. Cette distinction protège l’expérience sans affaiblir la vérité commerciale.
Ce travail rend les incidents plus bornés. Les équipes savent si elles doivent attendre une synchronisation, relancer un flux précis, revoir une donnée ou interrompre l’opération avant qu’elle ne produise un effet irréversible.
8. Sept lots de tests pour garder une livraison exploitable
Paralléliser les preuves sans raccourcir les contrôles
La chaîne d’intégration répartit les contrôles PHP en deux lots unitaires, quatre lots applicatifs et un lot d’intégration. Cette organisation conserve une vérification large tout en donnant plus vite l’origine d’un échec.
Les contrôles de syntaxe, d’architecture, de contrats et de sécurité peuvent avancer sans attendre les étapes dont ils ne dépendent pas. Les images de test sont réutilisées lorsque leur contenu n’a pas changé, afin de consacrer le temps de calcul aux modifications réelles.
La branche de sandbox construit et vérifie les images destinées à la préproduction. La branche de production reconstruit et contrôle ses propres images après validation. Une image ne devient donc pas livrable simplement parce qu’elle fonctionne sur le poste qui l’a produite.
Pour 1UP, cette parallélisation soutient le rythme du produit : une petite évolution reste rapide à qualifier, tandis qu’une modification transversale traverse l’ensemble des garde-fous avant d’atteindre les utilisateurs.
Risque métier et contrat attendu
Règles, interfaces et intégrations
Tests, sécurité et compatibilité
Image contrôlée et remise en ligne
Comportement conservé au lot suivant
9. Deux API protégées contre les ruptures silencieuses
Faire évoluer l’intérieur sans surprendre les applications connectées
La plateforme expose une API pour l’espace client et une API pour les usages commerciaux externes. Leurs ressources, champs obligatoires, exemples et réponses d’erreur forment un contrat consommé au-delà de l’écran principal.
Dawap compare chaque nouvelle version avec le dernier contrat effectivement livré. Un ajout compatible peut avancer ; la suppression d’un champ, le changement d’un type ou l’affaiblissement d’une règle est signalé avant la mise en production.
Les objets exposés par l’API sont séparés du stockage interne. Une évolution de la base ou du mapping Odoo ne modifie donc pas automatiquement la forme promise aux consommateurs. Le changement devient une décision explicite plutôt qu’un effet de bord.
Le même principe s’applique aux messages traités en arrière-plan. Leur identité et leurs données essentielles doivent rester compréhensibles lorsque deux versions de l’application coexistent quelques instants pendant une livraison.
10. Sécurité applicative et chaîne de livraison logicielle
Protéger les comptes, les actions sensibles et les images livrées
Les droits combinent le profil de l’utilisateur et son périmètre réel : compte client, portefeuille commercial, espace administratif ou logistique. Les contrôles sont appliqués dans les règles métier et les API, pas seulement dans les liens affichés à l’écran.
Les actions sensibles ajoutent les protections adaptées : confirmation, jeton CSRF, authentification multifacteur, limitation de fréquence et traçabilité. Les tentatives d’accès horizontal sont rejouées pour vérifier qu’un identifiant modifié ne suffit jamais à sortir de son périmètre.
Les journaux conservent le contexte utile au diagnostic sans recopier les secrets ni les contenus sensibles. Les données techniques sont masquées lorsqu’elles passent dans une erreur, un événement ou un outil de supervision.
Enfin, la livraison contrôle aussi les dépendances et la composition des images. Les secrets sont injectés par environnement et ne voyagent pas dans les images applicatives. La sécurité accompagne ainsi le parcours complet, du compte utilisateur jusqu’au composant déployé.
11. Observabilité et outils de diagnostic
Distinguer un retard de synchronisation d’une erreur métier
Les synchronisations Odoo, les traitements de vente, les exports, les documents et les reconstructions de stock disposent d’un état compréhensible. Les vues de monitoring séparent notamment la santé de RabbitMQ des messages déjà classés en échec, afin d’éviter un diagnostic trop large.
Une trace utile indique la famille du flux, son identité, sa durée, son statut et le point où reprendre. Elle ne recopie pas le panier, le document ou le secret complet. Cette discipline permet de rapprocher les événements sans créer une seconde fuite de données.
Les équipes peuvent ainsi distinguer une donnée en attente, une file indisponible, un rejet fonctionnel et une incohérence à revoir. Le support donne une réponse plus juste et l’incident rejoint directement le bon périmètre.
Cette chaîne entre signal, diagnostic, responsabilité et reprise correspond à notre approche de l’observabilité des applications et des API. Chez 1UP, elle est ancrée dans les flux réels de catalogue, de vente et de logistique.
12. Mettre à jour l’application sans perdre les sessions
Une maintenance visible, des contrôles de reprise et une réouverture conditionnelle
La plateforme repose sur Symfony 8, PHP, MySQL, Redis, RabbitMQ, Nginx et des images Docker. Les environnements de développement, de sandbox et de production partagent la même logique de services, tout en gardant leurs secrets et leurs données séparés.
Dawap a ajouté une passerelle permanente devant l’application. Pendant le remplacement des conteneurs, elle sert une page de maintenance explicite et conserve le trafic hors de la nouvelle version. La plateforme n’est rouverte qu’après les contrôles de disponibilité et le test du parcours de connexion.
Les sessions vivent dans un Redis dédié qui reste actif pendant la mise à jour. Lors de la première transition, les sessions encore valides sont transférées sans prolonger leur durée et sans écraser une session plus récente. Après la maintenance, chaque profil retrouve l’espace autorisé par ses droits actuels.
Les services de fond disposent eux aussi d’un arrêt contrôlé. Les fichiers persistants, les exports, les PDF et les journaux utiles sont montés dans les conteneurs qui les produisent ou les servent. Une nouvelle image ne doit jamais rendre indisponible un document simplement parce que son conteneur a changé.
Enfin, chaque tentative conserve les images précédentes et ses points de contrôle. Si la nouvelle version ne satisfait pas les vérifications, la maintenance reste active et le retour aux images connues peut être engagé sans improviser les étapes essentielles.
13. Reprendre les flux sans relancer tout l’historique
Borner l’incident avant d’autoriser de nouvelles écritures
Les traitements asynchrones portent une identité stable, des tentatives bornées et un état final. Les synchronisations Odoo, les reconstructions de disponibilité, les exports et les notifications peuvent ainsi être repris sur leur propre périmètre.
Après une mise en production, la reprise commerciale relit une fenêtre de temps limitée. Elle vérifie successivement les commandes, les livraisons, les factures, les avoirs et les paiements. Un étage ne s’ouvre que lorsque le précédent a produit l’état attendu.
Cette progression évite de reconstruire tout l’historique pour compenser une interruption courte. Elle réduit aussi le risque de pousser de nouvelles données sur une base encore incohérente. Une erreur ou un délai dépassé interrompt la procédure au lieu de laisser croire que la reprise est terminée.
Les notifications de commande utilisent en parallèle une boîte d’envoi durable. Une indisponibilité temporaire du transport de messages ou du service d’email ne fait donc pas disparaître l’information associée à un panier confirmé.
14. Une plateforme qui continue d’évoluer après son industrialisation
La qualité accompagne les nouveaux usages au lieu de figer le produit
L’industrialisation n’a pas marqué la fin du développement. La plateforme continue de recevoir des fonctions de vente et de logistique : commentaires de panier partagés entre web et API, filtres sur les bons de livraison, documents officiels, calculs de potentiel et nouvelles lectures Odoo.
Chaque ajout suit la même logique. La règle est placée dans le domaine concerné, les consommateurs existants sont identifiés, les erreurs sont rendues explicites et le parcours de livraison est complété lorsque le nouveau comportement l’exige.
Cette continuité évite le choix artificiel entre maintenir et innover. Les lots de refonte du logiciel métier retirent la dette qui bloque une évolution, puis la nouvelle capacité s’appuie sur une base mieux protégée.
Pour 1UP, le produit reste donc ouvert à de nouveaux processus sans redevenir une accumulation de correctifs. Les apprentissages de l’exploitation sont transformés en règles, en contrôles et en procédures réutilisables au lot suivant.
15. Ce que 1UP Distribution gagne au quotidien
Plus de continuité pour les utilisateurs et plus de maîtrise pour les équipes
Les sessions encore valides peuvent être conservées lors d’une mise à jour normale. Les clients professionnels retrouvent ensuite le bon espace selon leurs droits et continuent à consulter les prix, les commandes et les documents rattachés à leur compte, sans que l’interface soit la seule barrière de sécurité.
Les équipes de 1UP disposent de parcours distincts mais cohérents. Un commercial, un administrateur et un logisticien ne voient pas les mêmes actions, tout en travaillant sur des identités de commande, de client et de livraison qui restent partagées.
Les mises en production deviennent répétables : maintenance contrôlée, sessions persistantes, images identifiées, vérifications de santé et reprise bornée des flux. Si un contrôle échoue, le trafic n’est pas rouvert par optimisme.
Enfin, les évolutions restent possibles. La plateforme peut accueillir de nouveaux usages sans renoncer aux contrats, aux tests et aux gestes d’exploitation déjà acquis. La transformation complète de l’activité B2B montre comment ce socle soutient l’ensemble du produit.
Une décision technique reliée à un risque opérationnel
Une reprise est priorisée selon ce qu’elle protège : une commande, un droit, un contrat API, une reprise de flux ou une remise en ligne. La discussion ne repose plus seulement sur la beauté du code ; elle se rattache à un effet observable pour 1UP et ses utilisateurs.
Cette discipline aide aussi à ordonner la feuille de route. Une fonction qui traverse plusieurs contrats peut commencer par un lot de sécurisation ; une amélioration locale peut avancer plus vite lorsque ses frontières disposent déjà de leurs preuves.
La qualité reste un travail de produit
Les volumes, les dépendances et les modes d’exploitation évoluent. Une protection pertinente aujourd’hui doit donc être revue lorsqu’un nouveau canal, un nouveau profil ou une nouvelle étape logistique change la nature du risque.
Le socle industrialisé rend ce travail continu possible. Les équipes peuvent identifier la frontière concernée, ajouter le comportement attendu et enrichir la procédure d’exploitation sans repartir d’une connaissance uniquement orale.
16. Conclusion : industrialiser pour continuer à livrer
La continuité de service devient une propriété du produit
Chez 1UP Distribution, l’industrialisation protège des réalités très concrètes : le prix proposé, la commande confirmée, le document officiel, le stock promis, le compte autorisé et la session d’un utilisateur pendant une mise à jour.
Dawap a relié l’architecture, les contrats, les contrôles, les images et les procédures de reprise dans une même chaîne de livraison. Le projet peut continuer à changer parce que les points les plus risqués ne reposent plus uniquement sur la mémoire de l’équipe.
C’est l’objectif d’une refonte de logiciel métier bien conduite : conserver les usages qui font tourner l’activité, reprendre les fragilités par priorité et donner à chaque nouvelle version un chemin sûr jusqu’à la production.
