Context
The solution to be studied is based on a Java / Spring Boot microservices architecture, supplemented by a TypeScript / Angular micro‑frontend approach, a DSP based on Kafka, critical mass processing (Spring Batch), and several distinct PostgreSQL databases per business domain, supplemented by 360 views and a synchronized reference base used daily for statistical or reporting purposes. The solution is containerized and runs with Podman. Each business domain is supported by approximately 4 Java applications, each placed in a separate container. This solution is developed to replace, in an iso‑functional manner, another software already in place; the deployment of this solution therefore involves reusing data from the existing software. The metrics, as of 01/04/2026, highlight a significant application volume, of the order of 528,000 lines of code, including: ~475,000 Java lines, ~85,000 TypeScript / Angular lines, supplemented by SQL, CSS/SASS and various scripts. Insufficient performance in several key processes, potentially stemming from the implemented architecture, necessitates an independent, objective and actionable diagnosis.
Objectives of the Mission
Evaluate the overall performance of the application solution, both for current operation by users in transactional mode and for mass processing.
Analyze the relevance of the division into microservices with regard to functional responsibilities, inter‑application flows (synchronous and asynchronous), consistency and volume constraints.
Identify the root causes of observed or latent dysfunctions (performance, excessive coupling, BD contention, etc.).
Evaluate transactional robustness and data consistency management in a distributed context (choreography, outbox/inbox, idempotence).
Assess the level of resilience and observability (monitoring, metrics, logs, traceability, incident recovery) with regard to the SPW requirements.
Produce structured, prioritized and realistic recommendations to guide development decisions (refactoring, reorganization of services, targeted optimizations).
Assess the operational robustness of the solution in the face of incidents, application errors or degraded situations (exception management, behavior in the event of partial failure, continuity of service).
Identify structural technical risks likely to have a lasting impact on the performance, stability or maintainability of the solution.
Identify the risks and points of weakness linked to existing or planned data recovery mechanisms (quality, completeness, integrity, performance, etc.).
Identify the levers to strengthen internal control of the information system and secure continuity of service in the event of a change in the sourcing method.
Scope of the Mission
The scope covers in particular:
Backend microservices and associated PostgreSQL databases: data models, access, performance, replication and view strategies;
Inter‑service communications, including REST and SOAP APIs, event exchanges via Kafka/DSP (choreography), file exchanges via FTP;
Mass processing and continuous flows (Spring Batch, outbox/inbox, idempotence);
The application infrastructure that influences performance, to the extent that it directly impacts the observed behaviors.
Additionally, the mission includes analysis of planned mechanisms for data and document recovery (GED Alfresco/S3) and the impact of data recovery on overall performance, consistency in a distributed context and robustness of processing chains.
Deliverables
An executive summary for management, highlighting key findings, major risks and the main levers of action.
A detailed audit report, including supported findings, both qualitative and quantitative; argued and supported technical analyses.
A prioritized recommendations plan, crossing the criteria of impact, effort and risk.
A specific analysis relating in particular to: maintainability and robustness in the medium term; issues related to data recovery; dependence on the service provider.
A summary map of structuring technical risks, accompanied by management recommendations.
A restitution support (PowerPoint type), intended for governance bodies.
Prerequisites – Provider’s Skills
The service provider is expected to have an independent, factual and pragmatic approach; an ability to interact with expert teams (SPW, service provider, architects); a strong capacity for synthesis, particularly for decision‑making bodies; and a clear orientation toward concrete and actionable recommendations, compatible with the operational constraints of the program. Access to the relevant source code, architectural documents, document recovery descriptions and a dedicated application sandbox will be provided under the control of the SPW.
Required Skills
Excellent communication in French with management bodies.
Capacity for critical analysis and synthesis.
Autonomy and rigor.
Pragmatic approach oriented to operational recommendations.
#J-18808-Ljbffr