Le schéma n'est pas l'architecture
Tout le monde sait dessiner des boîtes et des flèches. Le vrai test arrive plus tard : la nuit où un service tombe, le mois où l'équipe double, l'année où le produit pivote. Une bonne architecture est celle qui rend ces trois moments ennuyeux.
Nous construisons et opérons des plateformes de réservation, des plateformes d'entreprise en sept langues et des SaaS multi-tenant. Ce qui suit n'est pas de la théorie. C'est ce qui a survécu.
Des couches, pas des spaghettis
Chaque système que nous livrons suit le même flux de données, du client vers le stockage :
- Frontend : l'interface, aussi mince que possible. Elle affiche, elle valide en surface, elle ne décide rien.
- Backend et APIs : toute la logique métier vit ici, testable, versionnée, documentée.
- Données : une source de vérité par domaine. Les copies sont des caches assumés, jamais des vérités concurrentes.
- Cloud et opérations : infrastructure décrite en code, déploiements automatisés, secrets hors du code.
Cette séparation paraît banale. Elle ne l'est pas. La plupart des systèmes que nous auditons mélangent logique métier et interface, ou laissent trois bases de données se contredire. Chaque couche qui fuit coûte des semaines plus tard.
Microservices ou monolithe : la mauvaise question
La question n'est pas combien de services, mais combien d'équipes et combien de rythmes de déploiement. Un monolithe bien découpé en modules bat une constellation de microservices mal découpés, à chaque fois.
Nous passons aux microservices quand deux conditions se rencontrent : des domaines métier qui évoluent à des vitesses différentes, et une équipe capable d'opérer la complexité supplémentaire. Sur une plateforme d'entreprise que nous opérons, les microservices .NET sur Azure se justifient : facturation, réservation et reporting changent à des rythmes différents et se déploient indépendamment. Sur un SaaS naissant, un monolithe Next.js plus PostgreSQL livre plus vite et se refactore sans douleur.
Le flux de données est le produit
Un architecte qui ne sait pas dessiner le chemin exact d'une donnée, de la saisie utilisateur au stockage puis au reporting, ne connaît pas son système. Nous documentons ce chemin pour chaque fonctionnalité critique : qui écrit, qui lit, qui transforme, qui archive.
C'est ce qui rend les intégrations sûres. Quand un site immobilier doit passer d'un CRM à un autre, la migration réussit parce que le flux est explicite : les annonces ont une source, les médias ont un pipeline, les leads ont un routage. On rebranche la source, le reste suit.
L'infrastructure est du code, ou elle n'existe pas
Un environnement qui ne peut pas être recréé depuis un dépôt Git est une dette. Terraform, Bicep ou l'outillage natif du cloud, peu importe l'outil : ce qui compte, c'est que la production soit reproductible, que la préproduction soit identique, et qu'un nouvel environnement se monte en heures, pas en semaines.
Même exigence pour la livraison : chaque commit passe par les tests unitaires, les tests de bout en bout et un déploiement automatisé. Cypress sur les parcours critiques nous a évité plus d'incidents que n'importe quelle revue de code.
L'observabilité avant le premier incident
Les logs structurés, les métriques et les alertes se mettent en place le premier jour, pas après le premier réveil à trois heures du matin. Notre règle : chaque événement métier important produit une trace exploitable, et chaque alerte doit être actionnable. Une alerte qu'on ignore deux fois est une alerte à supprimer ou à corriger.
Choisir l'ennui
PostgreSQL plutôt que la base à la mode. Des files de messages éprouvées plutôt que le dernier framework d'événements. Du code lisible plutôt que du code brillant. La technologie ennuyeuse a une propriété magique : elle est encore maintenue, documentée et recrutable dans cinq ans.
L'innovation, nous la réservons là où elle paie : l'intégration de l'IA dans les flux métier, l'automatisation des opérations, l'expérience utilisateur. Le socle, lui, reste ennuyeux. C'est pour cela qu'il tient.
Ce que cela change pour vous
Si vous faites construire un système, exigez trois choses : un schéma des flux de données que vous comprenez, une infrastructure reproductible depuis un dépôt, et des tests automatisés sur les parcours qui font votre chiffre d'affaires. Tout le reste est négociable. Pas ces trois-là.