Un nouveau produit à structurer
Avant d'écrire le code, il faut choisir les briques, le découpage, le modèle de données et la façon dont l'application et l'API se parlent.
Expertise
Architecture logicielle
qui tient quand
le produit grandit.
Conception et revue d'architecture logicielle pour applications mobiles, web et API : découpage en modules, modèle de données, contrats d'API, migrations progressives. Chaque choix structurant est documenté, avec ses alternatives et ses conséquences.
decisionsDÉCISION 0008
Migration progressive
Remplacer le module de paiement par étapes, derrière la même interface, plutôt que réécrire l’application.
ALTERNATIVE ÉCARTÉE
Réécriture complète : les évolutions seraient gelées pendant toute la reconstruction.
Conséquences
Deux implémentations coexistent pendant la migration ; chaque vague peut être livrée seule.
● DÉCISION ACCEPTÉECONTEXTE · ALTERNATIVES · CONSÉQUENCES
Situations
Quand l'architecture devient le sujet.
Un code qui ralentit chaque évolution
Chaque fonctionnalité en fragilise une autre, les dépendances sont emmêlées et l'équipe n'ose plus toucher certaines parties.
Une migration structurante
Changement de framework, de gestion d'état ou de base de données, à mener sans interrompre un produit en production.
Des décisions que personne ne retrouve
Les choix ont été faits, mais ni leurs raisons ni les alternatives écartées ne sont écrites. L'équipe qui arrive doit tout redécouvrir.
Périmètres couverts
Ce que nous concevons et documentons.
Une architecture se juge à ce qu'elle permet de changer sans tout casser. Nous la concevons, la documentons et la faisons évoluer avec l'équipe qui la maintiendra.
Architecture applicative
Découpage en modules, gestion d'état, navigation et dépendances pour les applications Flutter, Swift, Kotlin et Next.js.
API et backend
Modules métier, contrats d'API documentés, authentification et intégrations, sur NestJS et Node.js.
Modèle de données
Schémas PostgreSQL, migrations versionnées, choix entre base relationnelle et documentaire selon les usages.
Temps réel
Messagerie, diffusion et synchronisation : WebSocket, WebRTC, LiveKit ou LL-HLS selon la latence et le coût visés.
Migrations progressives
Remplacement par étapes selon le modèle Strangler Fig plutôt qu'une réécriture : le produit reste en production pendant la migration.
Décisions documentées
Diagrammes versionnés dans Git, contrats d'API et notes de décision : chaque choix structurant indique les alternatives considérées et ses conséquences.
Méthode
De l'existant à l'architecture cible.
- 01
Comprendre les contraintes
Usages, volumes, équipe, échéances et existant technique. Une architecture répond à des contraintes, pas à une mode.
- 02
Proposer et comparer
Architecture cible et options possibles, avec leurs coûts, leurs risques et ce qu'elles rendront difficile ensuite.
- 03
Documenter les décisions
Diagrammes, modèle de données, contrats d'API et notes de décision, versionnés avec le code.
- 04
Accompagner la mise en œuvre
Fondations, revue de code et migration par étapes, aux côtés de votre équipe ou en prenant en charge le développement.
Responsabilités
Ce qui revient à chacun.
Répartition courante des responsabilités, arrêtée mission par mission dans le contrat.
| Sujet | Chez vous | Chez Black Tide |
|---|---|---|
| Contraintes | Vous partagez les usages, les volumes et les échéances | Nous les traduisons en exigences d'architecture |
| Choix structurants | Vous validez l'option retenue | Nous proposons les options et documentons les conséquences |
| Documentation | Vous l'hébergez dans vos outils | Nous la rédigeons et la tenons à jour pendant la mission |
| Revue de code | Votre processus s'applique | Nous veillons au respect des choix d'architecture |
| Migration | Vous arbitrez le rythme et les priorités | Nous migrons par étapes, sans interruption de service |
Preuve
Des architectures éprouvées en production.
Blisterr
Migration progressive selon le modèle Strangler Fig : application Flutter passée par vagues à hooks et Riverpod, backend en cours de migration de MongoDB vers PostgreSQL, table par table, sans interruption de service.
Lire le cas BlisterrFantasy Alley
Trois blocs articulés : une application Flutter, une API NestJS d'une vingtaine de modules métier et un pipeline Python qui synchronise environ 125 000 livres.
Lire le cas Fantasy AlleyChaque cas décrit le travail réellement réalisé, son périmètre et son statut.
Budget et suite
Comment une mission d'architecture se cadre.
Ce que le cadrage détermine
Les questions d'architecture à trancher, l'existant à examiner et les livrables attendus : architecture cible, modèle de données, contrats d'API.
Ce qui compose le budget
Le temps de conception et de documentation, l'étendue de l'existant à examiner et l'accompagnement de la mise en œuvre, s'il est demandé.
Une architecture transmissible
Les livrables sont écrits pour être repris par l'équipe qui développe, la vôtre comme la nôtre.
Entrer à l'étape utile
Revue d'architecture seule, conception d'une architecture cible ou accompagnement complet de la mise en œuvre.
Questions utiles
Avant une mission d'architecture.
Faut-il des microservices ?
Pas par défaut. Un monolithe bien découpé en modules convient à la plupart des produits et reste plus simple à exploiter. Nous découpons en services quand une contrainte réelle le justifie.
Pouvez-vous intervenir sur une architecture existante ?
Oui. Nous examinons d'abord le code et l'exploitation, puis proposons une trajectoire d'évolution par étapes plutôt qu'une réécriture.
Quels livrables recevons-nous ?
Selon le périmètre : diagrammes d'architecture, modèle de données, contrats d'API et notes de décision, versionnés avec le code.
Travaillez-vous avec notre équipe technique ?
Oui. L'architecture est conçue avec l'équipe qui la maintiendra, en projet ou en renfort, pour que les choix soient compris et appliqués.
Prochaine étape
Parlons de votre architecture.
Votre produit, son existant technique et ce qui doit pouvoir évoluer : c'est le point de départ d'une revue utile.