Modular Monolith
Relevant for an MVP, a growing product, a small team, still manageable complexity.
Modern engineering to build systems that can evolve.
Sidéral Technologies combines software architecture, development, data, artificial intelligence, cloud, DevOps, integration and security to design robust digital solutions fitted to each organisation's reality.
Technology is not a collection of tools. It is a system of coherent choices in service of an objective.
Our philosophy
We do not choose a technology because it is fashionable.
A relevant architecture depends on the business problem, organisational maturity, data volume, integration needs, expected security, available skills, budget and evolution prospects.
01
Business Need
02
Constraints
03
Architecture
04
Technology Choice
05
Delivery
06
Operations
07
Evolution
The best stack is the one that remains relevant after the demo is over and the system is actually in operation.
Capability domains
Eight pillars, distinct practices.
This page does not explain what Sidéral builds for a business — that is the role of Solutions. It explains with which skills and engineering principles systems are designed.
Build fast, accessible and maintainable experiences.
Front-end is not decoration. It is where architecture meets use: components, server/client boundaries, performance, accessibility and internationalisation.
Technologies
- React
- Next.js
- TypeScript
- Tailwind CSS
- Vite
Capabilities
- Modern web applications
- SaaS interfaces
- Back offices
- Portals
- Dashboards
- Design systems
- Responsive layouts
- Accessibility
- Performance optimisation
- Internationalisation
- API integration
Principles
Component architecture
Compose reusable interfaces instead of duplicating screens.
Server/client boundaries
Decide clearly what runs on the server and what stays interactive.
Performance
Measure, then optimise. Performance is a feature.
Accessibility
Semantic HTML, keyboard, contrast, focus, reduced motion.
Maintainability
A design system and conventions so the product can live on.
SEO when relevant
SEO is not mandatory for a back office. It is for a public page.
01
Content
02
Routing
03
Render
04
Hydration
05
API
06
Cache
Build the business core with a clear, controlled architecture.
The back-end carries rules, contracts and operational truth. APIs, services, jobs and permissions are designed to stay readable, testable and observable.
Technologies
- Node.js
- Laravel
- Symfony
- FastAPI
- TypeScript
Capabilities
- REST APIs
- Business services
- Business applications
- Modular architecture
- Asynchronous services
- Queues
- Jobs
- Notifications
- Integrations
- Authentication
- Permissions
- Audit
- Reporting
Principles
Separation of concerns
Separate domain, infrastructure and presentation.
Domain logic
Business rules live in code, not only in the interface.
API contracts
Version, document and validate exchange contracts.
Validation
Never trust an uncontrolled input.
Observability
Logs, metrics and traces to understand an incident.
Security
Authn, authz, secrets and audit from design.
Testing
Unit, integration and API tests according to risk.
Documentation
An API without a readable contract is not deliverable.
01
Client
02
API
03
Domain
04
Persistence
05
Jobs
06
Integrations
Mobile apps designed for the field, not only for a demo.
Flutter or React Native according to team and product context. Offline is only promised when it is actually required. Variable connectivity, security and maintenance remain first-order constraints.
An offline-first architecture is not a default. It is justified by the business.
Technologies
- Flutter
- React Native
Capabilities
- Business applications
- Customer applications
- Field applications
- Offline when relevant
- Notifications
- Synchronisation
- APIs
- Geolocation when required
- Document handling
- Authentication
Principles
Expérience mobile
Short journeys, loading states, understandable errors.
Performance
Startup, fluidity and network use measured.
Connectivité variable
Design for the real network, not the office Wi-Fi.
Sécurité
Local storage, tokens, certificates: treated as architecture.
Maintenance
Stores, OS versions and SDK debt anticipated.
01
App
02
Auth
03
API
04
Sync
05
Local storage
06
Notifications
Useful data starts as accessible, reliable and structured data.
Modeling, quality, historisation and reporting. A dashboard does not only display numbers: it should help people decide. PostgreSQL, MySQL or SQL Server according to what exists — no database wars.
Technologies
- PostgreSQL
- MySQL
- SQL Server
- Python
- Power BI
- Metabase
Capabilities
- Modeling
- Cleansing
- Transformation
- Consolidation
- ETL / ELT
- Data warehouse
- Data mart
- Quality
- Historisation
- Migration
- Reporting
- Dashboards
- KPIs
- Data storytelling
Principles
Décider
A dashboard must not only display data. It must help people decide.
Définitions
Align indicators before aligning tools.
Adéquation
PostgreSQL is a strong option when it fits, not an obligation.
01
Sources
02
Ingestion
03
Transformation
04
Storage
05
Modeling
06
Analytics
Integrate AI as a business capability, not a gadget.
Generative AI, LLMs, RAG, agents, document intelligence: only where the use case, governance and human oversight hold. AI is not 100% reliable.
Nothing here claims that a model is infallible.
Technologies
- LLM
- RAG
- AI Agents
- FastAPI
- Python
Capabilities
- Business assistants
- Document search
- Document analysis
- Information extraction
- Assisted generation
- Process integration
- Orchestration
- Agents
- Automation
- Classification
- Semantic search
Principles
Human oversight
A human remains accountable for sensitive decisions.
Evaluation
Measure quality rather than relying on impression.
Security
Data, prompts and outputs treated as attack surfaces.
Data governance
Know which data the model is allowed to see.
Logging
Trace usage without exposing secrets in logs.
Cost control
The cost of a call is not an architecture detail.
Fallback strategies
A degraded path when the model fails or is unavailable.
01
User
02
Business Application
03
AI Orchestration
04
Context / RAG / Tools
05
Model
06
Business Systems
Evolve infrastructure together with the applications.
Cloud, Linux, containers, networking, storage, backups. No single provider is mandated. Kubernetes is not a reflex: it is justified. CI/CD according to the repository and organisation.
Technologies
- Docker
- Kubernetes
- Linux
- Cloud
- GitHub Actions
Capabilities
- Containerisation
- CI/CD
- Deployment automation
- Configuration
- Environments
- Monitoring
- Logging
- Rollback
- Secrets management
- Backup
- Load balancing
- Networking
Principles
Parité
Environments should resemble each other enough that deploy is not a leap into the void.
Complexité méritée
An orchestrator without an orchestration need adds load, not maturity.
01
Application
02
Runtime
03
Containers
04
Infrastructure
05
Network
06
Observability
Build the right architecture before accumulating technologies.
Modular monolith, SOA, microservices, event-driven, API-first, headless, multi-tenant SaaS: styles, not dogmas. Microservices are avoided when their complexity is not justified. Modern systems often coexist with what already exists.
Technologies
- Node.js
- FastAPI
- Laravel
- PostgreSQL
Capabilities
- REST APIs
- Webhooks
- Connectors
- API gateway
- Versioning
- Rate limiting
- Documentation
- ERP / CRM
- BI
- Identity
- Partner systems
- File exchanges
Principles
Interopérabilité
Connect systems rather than recreating silos.
Existant
Legacy is not a moral obstacle. It is an architecture constraint.
Pragmatisme
We avoid microservices when their complexity is not justified.
01
Need
02
Constraints
03
Style
04
Contracts
05
Integrations
06
Evolution
Security by design — not a module glued on at the end.
Identity, application, API, data, infrastructure, operations, users. Sidéral does not claim a SOC, certified pentest or regulated service here. Least privilege, secrets, dependencies, logs, backups and incident readiness.
No regulatory compliance claim without an audit and context.
Technologies
- OAuth2 / OIDC
- Keycloak
Capabilities
- IAM
- RBAC
- JWT
- OAuth2 / OIDC
- SSO
- MFA readiness
- Input validation
- Secrets management
- Audit
- Encryption
- Backups
Principles
Least privilege
Grant the minimum necessary, as late as possible.
Secure defaults
The safe path should be the default path.
Authentication vs authorization
Knowing who you are is not knowing what you are allowed to do.
01
Identity
02
Application
03
API
04
Data
05
Infrastructure
06
Operations
07
Users
Software architecture
Build the right architecture before accumulating technologies.
The styles below are options. None is mandatory. We avoid microservices when their complexity is not justified.
Modular Monolith
Still concentrated product, limited team, need for delivery speed.
- Simpler operations
- Simpler transactions
- Less internal networking
Low to medium complexity cost. The risk is entanglement if modules are not held.
Service-Oriented Architecture
Identifiable domains, need to expose reusable capabilities.
- Reuse
- Clearer contracts
Medium cost: service and version governance.
Microservices
Strongly separated domains, independent scalability, multiple teams.
- Independent deploys
- Failure isolation
High cost of operations, observability and consistency. Must be earned.
Event-Driven Architecture
Asynchronous flows, temporal decoupling, notifications and background processing.
- Decoupling
- Responsiveness
Cost of tracing, idempotence and error recovery.
API-first
Several consumers (web, mobile, partners) from the start.
- Stable contracts
- Easier integration
Versioning and documentation discipline.
Headless
Several experience channels around the same business core.
- Interface flexibility
- Reusable core
More integration surface between channels and API.
Multi-tenant SaaS
One product served to several organisations, with isolation and configuration.
- Scale effect
- Modules and plans
Isolation, RBAC, audit and data model to choose according to risk.
Complexity must be earned.
Microservices
Relevant when domains are strongly separated, independent scalability, multiple teams, or high operational constraints.
Modern architecture does not mean complicated architecture.
Reference architecture
A system is read in layers, not as a catalogue of tools.
This view does not require using every technology together. It shows how responsibilities connect.
Users
- Web
- Mobile
- Partners
Experience layer
- Next.js
- React
- Flutter / React Native
API / Access
- API Gateway
- Authentication
- Authorization
Business layer
- Domain Services
- Workflows
- Jobs
- Notifications
Intelligence
- AI
- Automation
- Analytics
Data
- Relational database
- Documents
- Cache
- Search
Integration
- External APIs
- Payment
- Messaging
- Partner systems
Infrastructure
- Cloud
- Docker
- Kubernetes
- Storage
Operations
- Monitoring
- Logging
- Backup
- CI/CD
Security
- IAM
- Audit
- Encryption
- Secrets
Compositions
Three reference architectures, not client projects.
Example only: every project gets a specific architecture choice.
Modern business platform
01
Next.js
02
FastAPI
03
PostgreSQL
04
Redis / Queue si nécessaire
05
Stockage S3-compatible
06
Docker
07
CI/CD
08
Monitoring
How we choose a stack
Criteria, not marketing scores.
No fictitious score is assigned here to a technology. The frame is for discussion, not to rank a market.
- 01Business Fit
- 02Team Skills
- 03Security
- 04Performance
- 05Scalability
- 06Maintainability
- 07Ecosystem
- 08Cost
- 09Time to Market
- 10Operational Complexity
- 11Longevity
Technology Radar
An editorial reading of the ecosystem, not a market study.
Internal, revisable classification. Using a technology is not a vendor partnership.
Technologies used regularly.
React
SaaS interfaces, portals, back offices and design systems.
Next.js
Modern web apps, SEO when relevant, Server Components.
TypeScript
Front-end, Node back-end and shared API contracts.
Tailwind CSS
Design systems, product interfaces and corporate sites.
Node.js
APIs, orchestration, jobs and business applications.
Laravel
Business core, back office, integrations and workflows.
FastAPI
Data services, AI, business APIs and integrations.
PostgreSQL
Business modeling, transactions, auditability.
Power BI
KPIs, executive dashboards and operational reporting.
Docker
Reproducible builds, deployment, environment parity.
Linux
Servers, containers, operations automation.
Cloud
According to constraints, budget, sovereignty and operating skills.
Using Microsoft, Google, OpenAI, Docker, Kubernetes or PostgreSQL is not an official partnership.
Primary stack
The currently preferred ecosystem, when it fits.
Experience
- React
- Next.js
- Flutter
- React Native
Application
- Node.js
- Laravel
- Symfony
- FastAPI
Data
- PostgreSQL
- MySQL
- SQL Server
Infrastructure
- Docker
- Kubernetes
- Linux
- Cloud
Intelligence
- LLM
- RAG
- AI Agents
- Power BI
- Metabase
Connect systems rather than recreating silos.
REST, webhooks, connectors, API gateway, authentication, versioning, rate limiting, documentation. Frequent cases: payment, ERP, CRM, partners, BI, messaging, identity.
Databases: skill before preference.
PostgreSQL, MySQL, SQL Server. Schema design, relations, indexing, performance, transactions, auditability, migration, backup, retention. No database wars.
Optimise where measurement shows a need.
Cache, Redis when relevant, query optimisation, CDN, images, server rendering, lazy loading, queues. Avoid premature over-optimisation.
Multi-tenant SaaS: isolation is a choice, not a slogan.
Tenant isolation, configuration, RBAC, plans, modules, feature flags, billing readiness, audit, data separation. Shared schema, separate schemas or separate databases: according to risk, not a single model.
Identity is part of the architecture.
JWT, OAuth2 / OIDC, Keycloak when relevant, SSO, MFA readiness, RBAC, sessions. Authentication: who you are. Authorization: what you can do.
Security by design.
Least privilege, secure defaults, validation, secrets, dependencies, logs, backups, patching, incident readiness. No SOC or certified pentest claimed here.
01
Identity
02
Application
03
API
04
Data
05
Infrastructure
06
Operations
07
Users
DevSecOps
Progressively integrate security checks into the cycle, without theatre.
01
Code
02
Review
03
Automated Tests
04
Dependency Checks
05
Build
06
Deploy
07
Observe
Quality is not a final phase.
Code review, standards, automated tests, manual QA, lint, typing, documentation, monitoring. Unit, integration, API, end-to-end, acceptance tests. No coverage figure is shown without measurement.
Know what happens when a system misbehaves.
Logs, metrics, tracing, alerts, dashboards. Making it run is not observing it.
Availability & resilience
Redundancy, backup, restore, health checks, failover when relevant, graceful degradation. No fictitious SLA.
A backup only has value if it can be restored.
Policies, retention, offsite copies, restore testing. RPO and RTO are notions to define per project, with no invented values here.
Documents & object storage
S3-compatible object storage, metadata, versioning, permissions, retention, audit — when the document business requires it. Natural link with DMS and document intelligence.
Performance is a feature.
Core Web Vitals, SSR / SSG, Server Components, images, code splitting, cache, bundle control. Indicative goals when relevant: LCP < 2.5 s, INP < 200 ms, CLS < 0.1. Real goals depend on the application context.
Accessibility
WCAG 2.2 AA as a design goal for public interfaces when applicable. Semantic HTML, keyboard, contrast, focus, screen readers, reduced motion. No automatic compliance certification.
Internationalisation
FR, EN, other languages if needed. Content separation, locale routing, date and currency formats, translation readiness.
Offline & limited connectivity
Local cache, queued operations, synchronisation, conflicts, network awareness — for some field projects. No systematic offline-first.
Payments & Mobile Money
Payment APIs, gateways, reconciliation, webhooks, audit. No operator named without a real integration. Sidéral is not a payment institution.
Notifications
Application events → notification service → email / SMS / push / in-app. Templates, preferences, logs, retry, multichannel.
01
Application Events
02
Notification Service
03
Email / SMS / Push / In-App
Workflow engineering
States, transitions, rules, approvals, tasks, deadlines, escalations, audit. Configurable processes when the business requires it.
01
Request
02
Review
03
Approval
04
Execution
05
Closure
Document Intelligence
Upload, OCR / extraction when needed, classification, metadata, index, RAG / search, user. OCR is not systematic.
01
Upload
02
OCR / Extraction
03
Classification
04
Metadata
05
Index
06
RAG / Search
07
User
Document the important choices.
ADR practice: context, decision, alternatives, trade-offs, consequences. Engineering that remembers.
- Context
- Decision
- Alternatives
- Trade-offs
- Consequences
Before architecture: technical discovery.
Existing systems, business constraints, security, data, integrations, users, traffic, budget, skills, operations. Possible outcome: architecture recommendation, risk register, technical roadmap.
Explore audit →Evolve without rewriting everything.
Audit, refactoring, API encapsulation, modularisation, migration, strangler pattern when relevant, cloud, UI modernisation. A full rewrite is not always the best decision.
Integrate with what exists.
Legacy databases, existing APIs, file exchanges, ERP, third parties. Modern systems often have to coexist with historical ones.
Build, integrate or buy?
Build, Buy, Integrate. Differentiation, cost, time, security, maintainability, lock-in, integration. Sidéral recommends a bought solution when it is more relevant than custom development.
Strategy advisory →Open source when it makes sense.
Flexibility, ecosystem, control, cost, community — and also maintenance, security, governance, skills. Open source is neither inherently better nor free.
Cloud, on-premise or hybrid.
Cloud: flexibility, scalability, managed services, rapid deployment. On-premise: control, specific constraints, legacy, requirements according to context. Hybrid: when justified. Architecture must follow project constraints.
Data governance
- Ownership
- Quality
- Access
- Security
- Retention
- Lineage
- Usage
AI governance
- Approved use cases
- Data access
- Prompt / model controls
- Evaluation
- Human review
- Monitoring
- Cost
- Security
Privacy by design
Minimisation, purpose limitation, permissions, retention, logs, safe storage. No GDPR or other regulatory compliance claim without an audit and context.
A good architecture must remain understandable to those who will keep it alive.
Architecture workshops, code reviews, pairing, documentation, transfer, training, handover.
Documentation is part of the product.
Diagrams, API documentation, deployment guides, runbooks, admin guides, technical decisions, user documentation. The list is configurable: not every document is promised for every engagement.
DevOps pipeline
01
Commit
02
Build
03
Test
04
Security Checks
05
Deploy
06
Monitor
07
Improve
We build the systems and can also transfer the skills needed to operate them.
- Power BI solution + Power BI training
- AI integration + adoption training
- Application deployment + administrator training
You already have an architecture, but you want it to evolve?
We can audit what exists, identify risks and propose an evolution path fitted to your constraints.
Explore New Possibilities
Let us build an architecture that meets today's needs without closing tomorrow's.
Tell us about your application, infrastructure, data or next product.