Dernière révision : 23 septembre 2026 · Nouveautés de la plateforme
Comment le code de la plateforme est organisé, construit et vérifié.
La plateforme est un projet Maven multi-modules. Le socle applicatif, le studio, le moteur, le CMS, la messagerie et le frontend y sont des modules distincts, assemblés par une distribution unique.
Le code et ses commentaires sont en anglais. Le texte affiché passe par les fichiers de traduction, dont la couverture est vérifiée à chaque construction. La documentation d'exploitation est écrite en français et en anglais.
Les libellés visibles nomment les briques par leur rôle — moteur de workflow, messagerie, coordinateur, registre — et non par la technologie qui les implémente. Le nom technique reste dans le code.
| Étape | Ce qu'elle produit | Bloquante |
|---|---|---|
| Compilation | les artefacts des modules | oui |
| Tests et couverture | les rapports de test et la tendance de couverture | instable si un test échoue |
| Complexité | un rapport par module | non |
| Nomenclature logicielle | l'inventaire des dépendances | non |
| Vulnérabilités | le rapport des dépendances vulnérables | instable si les critiques augmentent |
| Distribution | l'archive déployable | oui |
Le choix de laisser peu d'étapes bloquantes est délibéré : la base de code porte une dette dont un seuil dur arrêterait la chaîne dès le premier passage. Le seuil de couverture porte donc sur les lignes modifiées, ce qui empêche la dette de croître sans exiger de la rembourser d'un coup.
Un correctif s'accompagne du test qui échouait avant lui. La vérification porte sur le résultat observable — l'écran affiché, la ligne écrite, le message reçu — plutôt que sur le code de retour d'un appel.
Last revised 23 September 2026 · Platform changelog
How the platform's code is organised, built and checked.
The platform is a multi-module Maven project. The application core, the studio, the engine, the CMS, the messaging service and the frontend are separate modules, assembled into a single distribution.
Code and its comments are in English. Displayed text goes through the translation files, whose coverage is checked on every build. The operations documentation is written in French and in English.
Visible labels name the building blocks by their role — workflow engine, messaging, coordinator, ledger — rather than by the technology behind them. The technical name stays in the code.
| Step | What it produces | Blocking |
|---|---|---|
| Compilation | the module artefacts | yes |
| Tests and coverage | test reports and the coverage trend | unstable if a test fails |
| Complexity | one report per module | no |
| Software bill of materials | the dependency inventory | no |
| Vulnerabilities | the report of vulnerable dependencies | unstable if criticals increase |
| Distribution | the deployable archive | yes |
Leaving few blocking steps is deliberate: the code base carries debt that a hard threshold would stop the pipeline on from the very first run. The coverage threshold therefore applies to changed lines, which prevents the debt from growing without demanding that it be repaid at once.
A fix comes with the test that failed before it. Verification looks at the observable result — the rendered screen, the written row, the received message — rather than at the status code of a call.