Le projet en un coup d’œil
Trois workspaces, 25 flux Odoo, des APIs, de la logistique et de l’IA multiplient les frontières où une régression peut se cacher.
Dawap a structuré l’architecture, les tests, la CI, la sécurité, l’observabilité, les builds et les procédures de run.
Chaque gain de couverture ou de maintenabilité devient un seuil que la suite du projet ne peut plus dégrader silencieusement.
Une plateforme B2B devient critique bien avant d’atteindre des millions d’utilisateurs. Dès qu’elle porte les prix, les commandes, les documents, les réservations, la logistique et les décisions des équipes, une régression locale peut se transformer en erreur commerciale. La réponse ne consiste pas à ralentir chaque évolution : elle consiste à rendre la qualité mesurable et reproductible.
La scorecard stricte à 99/100 et la couverture PCOV à 100 % ne sont pas des arguments isolés. Elles résultent d’un même système de preuves : architecture mesurée, branches défensives testées, contrats verrouillés, maintenabilité ratchetée et limites encore ouvertes. La qualité est lisible parce que chaque chiffre renvoie à un artefact et à un contrôle qui peut échouer.
Dawap a mené ce travail comme un audit technique d’application web continu : mesurer, identifier le prochain levier, corriger, ajouter un garde-fou puis empêcher la régression. L’industrialisation n’est pas un sprint final ; elle accompagne chaque fonctionnalité.
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. Une plateforme devenue un système opérationnel
Pourquoi la qualité technique est une valeur métier chez 1UP
La plateforme 1UP Distribution rassemble un portail client, un cockpit commercial et une administration. Elle synchronise Odoo, expose des APIs, traite des jobs asynchrones, calcule une disponibilité, prépare des livraisons et héberge six assistants IA. Cette largeur augmente le nombre de scénarios et de responsabilités.
Le coût d’un défaut varie : un libellé peut ralentir une équipe ; un scope mal appliqué peut exposer un compte ; un doublon d’import peut créer une deuxième commande ; une projection incorrecte peut vendre un stock promis. La stratégie de qualité doit prioriser les invariants et les frontières selon leur impact.
Le socle technique doit également rester exploitable. Construire et déployer les images, lancer les workers, exécuter les crons, suivre les files, renouveler un secret, rejouer un flux et restaurer une situation font partie du produit livré.
2. Une boucle de qualité par preuve et ratchet
Ne jamais reperdre silencieusement un niveau atteint
La scorecard mesure plusieurs dimensions : architecture, domaine, infrastructure, API, expérience développeur, tests, maintenabilité et sécurité. Elle ne se contente pas d’une moyenne ; elle expose les points faibles et les preuves attendues.
Chaque chantier choisit un levier concret : découper un fichier trop grand, injecter un port de lecture, couvrir une branche de récupération, bloquer une rupture OpenAPI ou renforcer un scope. Une fois le seuil atteint, un test de qualité ou un ratchet empêche le retour en arrière.
Les changements traversent la CI, les revues, les environnements et les contrôles de production. Le suivi Jira classe chaque chantier selon le risque de régression, la dette qu’il retire et la preuve automatisée qu’il ajoute ; les sprints peuvent ainsi consolider le socle avant de relever un nouveau seuil. Les sujets à risque disposent de plans de rollout ou de handoff. Les limites non encore franchies restent marquées comme telles afin de ne pas confondre préparation et preuve finale.
3. Les risques d’une plateforme qui grandit vite
La complexité se déplace plus vite qu’elle ne disparaît
Le premier risque est le couplage. Si une règle de stock se retrouve dans un contrôleur, un mapping Odoo et un script de dashboard, chaque évolution demande de retrouver toutes ses copies. Le comportement divergent apparaît ensuite selon le canal.
Le deuxième risque est la confiance excessive dans le chemin heureux. Un import fonctionne tant que l’ERP répond, une file tant que le message est valide, une permission tant que l’utilisateur suit les liens prévus. Les incidents réels surgissent dans les retries, payloads manipulés, dates limites et réponses partielles.
Le troisième risque est le poids de la suite elle-même. Des milliers de tests inutilisables s’ils prennent trop longtemps ou échouent aléatoirement deviennent un frein. La CI doit donner une réponse rapide, reproductible et suffisamment riche pour diagnostiquer.
Une métrique n’est utile que si elle protège une capacité métier et si le pipeline empêche sa régression. Le volume seul n’est jamais présenté comme une garantie absolue.
La dette apparaît d’abord aux frontières
Une fonctionnalité peut sembler correcte dans son écran tout en fragilisant le système : contrat API modifié, message impossible à relire après un déploiement, mapping externe dupliqué ou règle de sécurité appliquée seulement dans l’interface. Ces défauts se déclarent tard parce qu’ils vivent entre deux composants.
L’industrialisation a donc ciblé les frontières aussi fortement que le domaine. Tests d’architecture, contrats OpenAPI, fixtures Odoo, scénarios de scope et identités asynchrones vérifient ce qui doit rester compatible lorsqu’une couche évolue.
Pourquoi “avoir beaucoup de tests” ne suffit pas
Une suite peut accumuler des cas faciles, ralentir le delivery et laisser intactes les branches qui déterminent la reprise. Le nombre ne devient une preuve qu’avec une structure : niveau de test adapté, assertions sur l’effet, exécution reproductible et diagnostic suffisamment rapide pour être utilisé quotidiennement.
Les travaux ont donc porté autant sur la qualité et la distribution de la suite que sur sa taille. Les scénarios rares mais coûteux — timeout, retry, donnée absente, scope croisé, état incohérent — ont reçu des tests dédiés.
4. Architecture par domaines et ports
Séparer les règles, les orchestrations et les adaptateurs
Le code organise les contextes de CRM, catalogue, panier, ventes, achats, disponibilité, livraison, finance, IA, sécurité et monitoring. Les règles de domaine restent indépendantes des contrôleurs et des réponses HTTP. Les cas d’usage orchestrent les ports nécessaires.
Les adaptateurs Doctrine, Odoo, fichiers, messages et modèles IA implémentent ces ports. Cette organisation permet de tester une règle sans démarrer tout l’environnement et de remplacer une lecture sans réécrire le domaine.
Des tests d’architecture surveillent les dépendances et le comptage des contrôleurs. Les refactorings structurants ont injecté des ports de lecture et retiré des accès directs qui empêchaient la séparation. Les bounded contexts suivent les décisions métier plutôt que les dossiers d’un framework.
Pour une entreprise confrontée à une base existante, notre page audit technique d’application web décrit la démarche de diagnostic ; 1UP montre le résultat d’une correction continue.
5. Maintenabilité mesurée
Découper les concentrations de risque avant qu’elles ne bloquent le delivery
La scorecard suit la taille des fichiers, les dépendances, les duplications et les responsabilités. Dans le rapport de référence, aucun fichier PHP de production n’atteint 650 lignes ; le maximum observé est de 649 lignes et le ratchet à ce palier est fermé à zéro.
Ces chiffres sont lus comme un radar, pas comme une norme universelle. Un fichier long mais cohérent peut être moins risqué qu’une logique éclatée ; le seuil sert à déclencher une revue. Les plus grosses surfaces ont été divisées par support fonctionnel : disponibilités, livraison, IA, catalogues, factures et recherche.
Les feuilles et scripts frontend surdimensionnés ont également été séparés. La navigation admin, les dashboards et modales sont découpés pour réduire les collisions. Les helpers de présentation ne reçoivent pas la responsabilité des règles métier.
Le ratchet interdit d’ajouter une nouvelle concentration sans décision explicite. Le score de maintenabilité progresse ainsi par réduction du risque, pas par renommage cosmétique.
6. 22 991 tests et 239 326 assertions
Une suite large, mais structurée par niveau de preuve
Le rapport JUnit de référence exécute 22 991 tests et 239 326 assertions sans failure, error ni skipped. La suite couvre le domaine, les cas d’usage, les adaptateurs, les contrôleurs, les contrats API, la sécurité, les commandes et les interfaces critiques.
Les tests unitaires isolent les calculs de stock, allocations, validations et normalisations. Les tests applicatifs vérifient les orchestrations et erreurs. Les tests d’intégration utilisent Doctrine, les files, des fixtures Odoo et les contrats réels lorsque la frontière doit être prouvée.
Les parcours de récupération ont été explicitement ajoutés : retries, réponses manquantes, snapshots périmés, imports partiels, erreurs de modèle, scopes croisés, documents absents et états terminaux incohérents. Cette densité défensive explique une grande partie du volume.
La suite ne prétend pas simuler l’ensemble de la production. Les interactions avec des services externes et les volumes réels demandent aussi des validations d’environnement, des tests de charge ciblés et une supervision post-release.
7. 100 % de couverture PCOV stricte
Clôturer les lignes mesurées sans confondre couverture et correction
La campagne PCOV canonique fusionnée atteint 199 892 statements couverts sur 199 892 mesurés. La progression a été menée par lots ciblés : contrôleurs, gardes, DTO, fallbacks, mappers, commandes et branches d’erreur.
La couverture est fusionnée depuis plusieurs shards et vérifiée exactement. Des tests garantissent que la configuration, les exclusions et les fichiers de rapport ne permettent pas de déclarer un pourcentage supérieur à la réalité. Les seuils augmentent par ratchet.
Cent pour cent ne signifie pas que toutes les assertions possibles existent. Une ligne peut être exécutée sans que son effet soit suffisamment vérifié. C’est pourquoi la scorecard sépare couverture, qualité des tests, architecture et sécurité.
La valeur de la mesure est néanmoins concrète : aucune ligne mesurée ne reste complètement hors du champ de la suite. Les futures modifications disposent d’un filet et ne peuvent pas réduire le seuil sans faire échouer la CI.
8. Une CI répartie en 7 shards
Garder un feedback exploitable malgré la taille de la suite
Les tests PHP sont répartis en sept shards afin d’exécuter les familles en parallèle. Les artefacts de couverture sont produits séparément puis fusionnés. Les contrôles de lint, architecture, qualité et contrats peuvent s’exécuter dans des jobs adaptés.
Les images de test PHP sont réutilisables et découplées des builds source lorsque cela évite du travail inutile. Les problèmes de cache runner et d’overlay ont été traités sans affaiblir les preuves. La CI conserve les fichiers d’environnement versionnés nécessaires à ses images.
L’ordre des jobs priorise les signaux rapides et la couverture. Une erreur de syntaxe ou de contrat doit remonter avant un build coûteux. Les rapports permettent d’identifier le shard et le test concernés plutôt qu’un simple statut rouge global.
Cette architecture CI protège la vitesse de delivery. Une suite énorme qui termine trop tard finit contournée ; le parallélisme garde la qualité dans la boucle quotidienne.
Risque métier et contrat attendu
Domaine, ports et adaptateurs
Tests, sécurité et compatibilité
Build reproductible et handoff
Seuil conservé et run observé
9. Contrats API, schéma et migrations
Empêcher qu’un refactoring interne casse une frontière externe
Les schémas OpenAPI des APIs client et commerciale sont comparés afin de bloquer les changements incompatibles. Les DTO et mappers donnent un contrat stable sans exposer directement les entités de persistance.
Les migrations sont contrôlées et les impacts directs testés. Les contraintes d’unicité Odoo, relations et champs obligatoires reflètent les invariants qui doivent survivre aux imports. Les rollouts sensibles conservent les snapshots ou étapes nécessaires au retour.
Les fixtures externes sont validées pour détecter un exemple devenu incohérent avec le mapping. Les payloads et réponses d’erreur documentés font partie de la qualité du contrat, pas seulement de la documentation.
Le même principe s’applique aux messages asynchrones : leur identité, données minimales et version doivent rester compréhensibles entre deux releases qui coexistent pendant un déploiement.
10. Sécurité applicative et supply chain
Rôles, scopes, MFA, dépendances et preuves
La plateforme combine contrôles de rôles, scopes de compte et portefeuille, protections anti-IDOR, CSRF, MFA, confirmations, rate limiting, redaction et audit. Les tests vérifient les accès horizontaux et les changements de scope des tokens.
Les identités administratives et commerciales sont traitées avec leurs contraintes. Les resets MFA sont couverts, l’impersonation encadrée et les espaces d’écriture prix séparés. Les événements de connexion alimentent les lectures de monitoring.
La supply chain suit les dépendances et produit un SBOM. Les mises à jour de sécurité sont intégrées et les images construites de façon reproductible. Les secrets restent fournis par environnement et ne sont pas incorporés aux artefacts.
La dimension sécurité de la scorecard reste à 97/100. La CSP a été préparée et observée, mais l’enforcement complet de production reste un passage à franchir. Cette limite explique pourquoi un score élevé n’est pas arrondi artificiellement à la perfection.
11. Observabilité et outils de diagnostic
Voir les files, flux, erreurs et décisions
Les activités API, synchronisations Odoo, tâches IA, exports et reconstructions disposent d’états et de traces. Les dashboards de monitoring séparent les catégories d’incident et mettent la scorecard en évidence pour suivre le niveau global.
Les alertes peuvent rejoindre les canaux prévus, avec des tests sur la télémétrie. Les contrôleurs de monitoring utilisent des ports de lecture injectés plutôt que des accès directs, ce qui rend les requêtes et permissions testables.
Les logs cherchent un équilibre entre diagnostic et confidentialité. Ils conservent l’identité, le type, la durée et le statut utiles sans recopier les données sensibles. Les erreurs externes sont normalisées afin d’être agrégées.
L’observabilité sert aussi le support : distinguer un flux en retard d’une règle métier évite une mauvaise réponse au client et oriente l’incident vers la bonne équipe.
12. Build, déploiement et environnements
Faire de la mise en production un processus répétable
La stack repose sur PHP 8.4, Symfony 8, MySQL, Redis, RabbitMQ, Docker, Nginx et PHP-FPM. Les images applicatives sont construites par la CI avec les extensions et configurations prévues, puis déployées avec les workers, crons et volumes nécessaires.
Les environnements de développement, sandbox et production partagent une logique proche tout en séparant les secrets et données. La sandbox permet de valider les imports, annulations et workflows sans écrire dans le mauvais périmètre Odoo.
Les stockages générés sont versionnés lorsque plusieurs releases peuvent se chevaucher. L’email transactionnel dispose d’un outbox durable, ce qui réduit le risque qu’une invitation ou notification soit perdue entre la transaction et le transport.
Les handoffs de mise en production documentent les migrations, tâches d’initialisation, workers, contrôles et points de retour. Le déploiement devient un objet vérifiable, pas la mémoire d’une commande lancée une fois.
13. Reprise, résilience et limites opérationnelles
Préparer l’incident sans prétendre qu’il n’arrivera pas
Les jobs possèdent retries, identités stables et états terminaux. Les replays Odoo sont contrôlés ; les reconstructions de disponibilité sont reprenables ; les exports et runs IA peuvent retrouver leur progression. Les files distinctes limitent la propagation d’un blocage.
Les fallbacks sont testés pour les documents, images, sources externes et modèles IA. Un fallback ne doit pas transformer une erreur critique en donnée valide : il sert l’expérience uniquement lorsque la règle métier l’autorise.
Le programme maintient un point NO-GO sur l’exercice complet de recovery de production tant qu’il n’a pas été exécuté avec la preuve attendue. Les sauvegardes et procédures ne sont pas assimilées à un rétablissement réellement testé.
Cette limite est saine. Une plateforme critique gagne en maturité lorsqu’elle distingue la présence d’un mécanisme, son test automatisé et la preuve d’un exercice opérationnel grandeur nature.
14. Lire la scorecard stricte 99/100
Une synthèse utile seulement si ses dimensions restent vérifiables
La scorecard courante atteint 99/100. Architecture, domaine, infrastructure et API sont à 98 ; tests, maintenabilité et expérience développeur à 100 ; sécurité à 97. Les notes reposent sur des preuves versionnées et des tests de garde.
Le score global ne gomme pas la dimension la plus basse. La sécurité à 97, les dépendances concrètes restantes, la CSP et le recovery drill expliquent les travaux encore ouverts malgré la fermeture de la couverture et des ratchets de maintenabilité.
Cette séparation entre preuves permet de raconter une amélioration réelle. Les nombres ne sont pas choisis pour produire un effet d’annonce ; ils servent à décider du prochain chantier et à empêcher le relâchement.
L’article scorecard de production d’une intégration API donne une grille de lecture générale complémentaire.
15. Résultats obtenus
Une plateforme riche qui garde sa capacité d’évolution
Le résultat est un produit dont les fonctionnalités critiques disposent de règles isolées, de contrats, de tests et d’outils de run. Les équipes peuvent livrer sur le portail, le commercial, Odoo, le stock, la logistique ou l’IA sans accepter qu’une zone reste hors contrôle.
Les chiffres rendent l’état auditable : 22 991 tests, 239 326 assertions sans failure, error ni skipped, 100 % PCOV sur 199 892 statements mesurés et une scorecard stricte à 99/100. Les limites de CSP et de recovery restent publiées.
La valeur métier se trouve dans la continuité : moins de divergences silencieuses, des replays encadrés, des scopes prouvés, des déploiements reproductibles et des diagnostics qui raccourcissent le chemin vers la cause.
Cette industrialisation soutient les sept autres projets. La transformation complète de l’activité B2B montre comment toutes ces capacités forment un même système.
Ce que les métriques changent dans une décision technique
Une proposition de refactoring peut être évaluée par la dépendance qu’elle retire, la branche qu’elle rend testable ou le seuil qu’elle protège. La discussion ne repose plus uniquement sur une préférence de style : elle se rattache à une concentration de risque et à une preuve attendue.
Cette discipline aide aussi à arbitrer la roadmap. Une fonctionnalité qui traverse un contrat critique peut exiger un lot de sécurisation avant d’être ouverte ; une amélioration locale peut être livrée plus vite si les frontières concernées sont déjà protégées.
La qualité reste un système vivant
Une couverture fermée, un score élevé ou un fichier sous un seuil ne doivent pas figer l’architecture. Les volumes, les dépendances et les modes d’exploitation évoluent ; les preuves doivent donc être recalculées et les contrôles adaptés lorsque le risque change.
Les limites publiées jouent ici un rôle utile. La CSP et l’exercice de recovery donnent les prochains objectifs concrets, rappellent la différence entre mécanisme disponible et protection démontrée, puis empêchent le score global de masquer le travail restant.
16. Conclusion : faire de la qualité une capacité produit
Mesurer, prouver, ratcheter et continuer
L’industrialisation de 1UP Distribution n’est pas une couche technique séparée du client. Elle protège les prix, les commandes, les scopes, les documents, les réservations et les décisions que les autres projets rendent visibles.
Dawap a construit une boucle où chaque amélioration produit une preuve et un garde-fou. Les chiffres sont élevés, mais les limites restent lisibles : c’est précisément cette absence de perfection artificielle qui rend la scorecard crédible.
Pour auditer ou reprendre une application confrontée au même enjeu, notre offre d’audit technique d’application web est le bon point d’entrée. Cette étude de cas montre ce que devient l’audit lorsqu’il est prolongé jusqu’à l’exécution.
