Our technical expertise
Architecture, DevOps, cloud, networks, AI: our know-how in interactive diagrams.
Paused
Swipe to explore the diagram, tap a block for its explanation.
Normal traffic: requests are spread across servers, the cache answers frequent reads.
- Availability
- 99.99 %
- p99 latency
- 120 ms
- Requests / s
- 1,250
Scenarios
Read the diagram as text
Diagram elements
- Clients
- : Your users' browsers and mobile apps, anywhere in the world.
- CDN
- : Servers close to your users: images, scripts and static pages are served in milliseconds.
- Load balancer
- : Sends each request to an available server and automatically removes those that stop responding (health checks).
- App 1
- : Stateless application server: any of them can handle any request.
- App 2
- : A second identical server: if one fails, the others take over.
- App 3
- : A third server: capacity is adjusted by adding or removing servers.
- App 4
- : Server started automatically during a traffic spike, then stopped when the load drops.
- Cache
- : Keeps frequently read data in memory: less load on the database and faster responses.
- PostgreSQL
- : Primary database: every write goes through it.
- Replica
- : Continuously synchronised copy, ready to take over if the primary database fails.
- Queue
- : Sets long tasks aside (emails, PDFs, payments) so the user gets an immediate response.
- Workers
- : Process queued tasks at their own pace, without slowing the site down.
Scenarios
A server fails
- App 2 stops responding: requests sent to it fail.
- The load balancer detects the failure and redistributes traffic to App 1 and App 3.
- App 2 restarts and passes its health checks again.
- Back to normal: your users noticed nothing.
Traffic spike
- Traffic spike: four times more requests, servers are saturated.
- Autoscaling: a fourth server starts automatically.
- The load is spread over four servers: latency goes back down.
- The spike is over: the extra server stops, you only pay for what you use.
Clean, testable, maintainable code
Object-oriented programming organises code into objects that bundle data and behaviour. Applied well, its four pillars make an application easier to understand, test and evolve: you add a feature without breaking everything. It is the foundation of how we code, and a key module of our training courses.
- Code structured with SOLID principles
- Business logic covered by automated tests
- Systematic code review
- OOP and design pattern training
Diagram elements
- CarnetDeSante
- : Class used through composition: each animal owns its own record.
- Animal
- : Abstract class: it defines what every animal can do, but cannot be instantiated as such.
- Domestique
- : Interface: a contract classes commit to, without dictating how.
- Chien
- : Inherits from Animal and implements Domestique; adds its own behaviour: rapporter() (fetch).
- Chat
- : Inherits from Animal and implements Domestique, with its own version of crier() (speak).
Animation walkthrough
- Encapsulation: the animal's data is protected and only reachable through controlled methods.
- Inheritance: Chien and Chat reuse everything Animal can do, without rewriting it.
- Polymorphism: the same crier() call returns “Woof!” or “Meow!” depending on the object.
- Abstraction: Animal and the Domestique interface set a contract, each class fulfils it its own way.
- Bonus, composition: an Animal owns a CarnetDeSante (health record), created and destroyed with it.
Ship often, without breaking production
Every code change goes through an automated chain: checks, tests, Docker image build, deployment to staging and then production. If a test fails, nothing is deployed. You get new features more often, with fewer bugs and no downtime.
- Continuous integration and delivery (GitHub Actions, GitLab CI)
- Identical Docker containers from laptop to production
- Staging environment to validate every release
- 24/7 monitoring and alerting
Diagram elements
- Developer
- : Code is written and tested locally, on a branch dedicated to the feature.
- Git push
- : The central repository keeps the history of every line of code; each push triggers the pipeline.
- Lint
- : Automatic code analysis: consistent style and common mistakes caught before testing.
- Tests
- : Hundreds of tests check within minutes that nothing is broken.
- Build
- : The code is compiled, minified and optimised for production.
- Docker image
- : The application and all its dependencies in a container: it runs the same everywhere.
- Registry
- : Every version of the image is kept: rolling back takes seconds.
- Staging
- : An exact copy of production to test under real conditions.
- Validation
- : Automated end-to-end tests and feature sign-off by the customer.
- Production
- : Servers are updated one by one: the site never goes down.
- Monitoring
- : Dashboards and alerts: an issue is caught before your customers notice it.
Zones
- Continuous integration (CI)
- : Automatic on every push: if a step fails, the rest is blocked.
- Continuous delivery (CD)
- : The same image is deployed to staging then production: what was tested is exactly what goes live.
Animation walkthrough
- The developer finishes a feature and its tests on their branch.
- git push: the code reaches the repository and the pipeline starts automatically.
- Lint: style and common mistakes are checked.
- Unit and integration tests: every feature is checked.
- Build: the code is compiled and optimised for production.
- A Docker image is built: identical on every environment.
- The image is versioned and stored in the registry.
- Automatic deployment to staging.
- End-to-end tests and customer sign-off on staging.
- Zero-downtime production release.
- Monitoring: logs, metrics and alerts watch over production.
- Metrics and user feedback feed the next iteration.
Scenarios
A test fails
- A new push… with a hidden regression.
- Lint: style and common mistakes are checked.
- A test fails: the pipeline stops, nothing reaches production.
- The developer is alerted with the test report and fixes it.
- Fix pushed: the pipeline starts over.
A secure, tailored cloud infrastructure
We deploy your applications with the provider that fits your budget (AWS, Azure, Google Cloud, OVHcloud or a VPS) using a segmented architecture: only the entry point is exposed to the Internet, servers and databases stay in private subnets. Hover over each element to see its role.
- Segmented private network (VPC, subnets, firewall)
- Managed, backed-up, replicated databases
- Automatic scaling based on traffic
- Infrastructure as code (Terraform), reproducible
Diagram elements
- Users
- : Your visitors come in from the Internet, over HTTPS only.
- Load balancer
- : Terminates HTTPS encryption and spreads traffic across healthy instances.
- Instance 1
- : Virtual machine running your application in a container.
- Instance 2
- : A second instance, in another availability zone to survive a datacenter outage.
- Instance 3
- : Instance added automatically when load rises, removed when it drops.
- Managed DB
- : Provider-managed database: updates, daily backups and encryption included.
- Standby
- : Synchronised copy in another zone: automatic failover if the primary fails.
- Object storage
- : Files, images and backups stored durably and cheaply, away from the servers.
Zones
- VPC · virtual private cloud
- : Your private network in the cloud, isolated from other customers: nothing gets in without an explicit rule.
- Public subnet
- : The only subnet exposed to the Internet: it only holds the load balancer.
- Private · application
- : Application servers, invisible from the Internet, in an autoscaling group.
- Private · data
- : Databases, only reachable from the application servers.
Scenarios
Load increase
- A marketing campaign triples traffic: instance CPU climbs.
- The autoscaling group launches a third instance.
- The load is shared: CPU and response time go back down.
- Traffic drops: the extra instance is removed, and so is its cost.
A reliable, segmented business network
We design and install your office network: fibre, firewall, switches, professional Wi-Fi and video surveillance. Each use has its own virtual network (VLAN): guests enjoy the Wi-Fi without ever seeing your workstations or cameras, and the firewall filters everything coming from the Internet.
- Firewall and secure remote access (VPN)
- Separate VLANs: office, guests, cameras
- Professional Wi-Fi covering all your premises
- IP video surveillance viewable on mobile
Diagram elements
- Internet
- : Your fibre or 4G access, optionally backed up by a second line.
- Firewall
- : Filters everything coming in and out, blocks intrusions and enables secure remote work (VPN).
- Switch
- : Connects all devices and separates the VLANs: each network stays in its lane.
- Workstations
- : The team's computers, wired for stability.
- Server
- : Shared files and automatic company backups.
- Wi-Fi AP
- : Professional access points: one network for the team, another for guests.
- Guests
- : Visitors' devices reach the Internet, and nothing else.
- NVR
- : Records video streams 24/7; secure viewing from your phone.
- IP cameras
- : Cameras powered over the network cable (PoE), on a dedicated VLAN.
Zones
- VLAN 10 · Office
- : The team's workstations and file server.
- VLAN 20 · Guest Wi-Fi
- : Internet access only, fully isolated from the rest of the network.
- VLAN 30 · CCTV
- : Cameras and recorder on a dedicated network, unreachable from the Internet.
Scenarios
Intrusion attempt
- A bot on the Internet scans your address looking for the cameras…
- …the firewall blocks all unauthorised inbound traffic and logs the attempt.
VLAN isolation
- A guest device tries to reach the video recorder…
- …denied: the guest VLAN only reaches the Internet. Your data stays segmented.
Fast, secure mobile apps
A mobile app is only the visible part. Behind it, a secure API authenticates every request, routes it to the right service and sends push notifications at the right time. We build the app and all the infrastructure that runs it, all the way to store publication.
- iOS and Android from a single codebase (Flutter)
- Secure API: JWT tokens, OAuth 2, rate limiting
- Targeted push notifications
- Publishing on the App Store and Google Play
Diagram elements
- Mobile app
- : The app installed on the phone, smooth even on a slow connection.
- API Gateway
- : The API's single entry point: encryption, access control and request rate limiting.
- Auth
- : Checks the user's identity and the validity of their token on every request.
- Services
- : The core of your app: orders, payments, profiles…
- Database
- : Stores your users' data, encrypted and backed up.
- Notifications
- : Sends push notifications through Google (FCM) and Apple (APNs) services.
Animation walkthrough
- The app sends an HTTPS request with the user's token.
- The API Gateway has the token checked by the authentication service.
- Valid token: the request is sent to the right service.
- The service reads and saves data in the database.
- The response gets back to the app within tens of milliseconds.
- An event (order shipped, new message…) triggers a push notification.
- The phone shows the notification, even with the app closed.
AI that answers from your own data
RAG (retrieval-augmented generation) connects a language model to your documents. Before answering, the AI retrieves the relevant passages from your knowledge base and relies on them: answers are accurate, up to date and sourced. Ideal for a customer assistant, internal support or searching your procedures.
- An assistant that knows your documents, with no data leaks
- Sourced answers, far fewer made-up facts
- Integration with your website, WhatsApp or tools
- Automatic updates when your documents change
Diagram elements
- Documents
- : Your content: procedures, catalogues, FAQ, contracts, web pages…
- Question
- : A question asked in natural language, on your website or WhatsApp.
- Embeddings
- : Turns text into a vector: texts with similar meaning get close vectors.
- Vector DB
- : Finds the passages closest to the question within milliseconds.
- LLM
- : The model writes the answer relying only on the passages provided.
- Answer
- : A clear answer, citing the documents so it can be checked.
Animation walkthrough
- Indexing: your documents are split into passages and converted into vectors.
- A user asks a question.
- The question is converted into a vector too.
- Searching the closest passages in the vector database.
- The LLM receives the question and the relevant passages from your documents.
- Generating the answer, token by token, citing the sources.
- A reliable answer, grounded in your data rather than guesswork.