Comment nous préparons l’architecture à une croissance ×10

La plupart des plateformes sont conçues pour les utilisateurs qu’elles ont déjà. C’est raisonnable le premier jour. Au quatre-centième, quand l’entreprise a doublé de taille, s’est installée dans un deuxième pays et a ajouté une langue que personne n’avait prévue, la facture devient salée.

Préparer la croissance ne veut pas dire tout construire d’un coup. Il s’agit de prendre tôt les quelques décisions sur lesquelles il est difficile de revenir, et de garder tout le reste simple. Voici notre façon de faire.

Partir de la cible

Avant de choisir la moindre technologie, nous notons les chiffres que l’entreprise vise : nombre d’utilisateurs, régions, volume de transactions, langues. Chaque décision d’architecture est ensuite confrontée à cette cible plutôt qu’au trafic du trimestre en cours.

Inutile d’être précis. « Une dizaine de sociétés dans le groupe, trois pays, le français, l’anglais et l’arabe, quelques milliers de salariés » suffit déjà à écarter certaines options et à en conforter d’autres. Nos questions sont simples :

• Combien d’organisations partageront la plateforme, et leurs données doivent-elles être strictement cloisonnées ?
• Quelles langues et quels sens d’écriture l’interface devra-t-elle gérer ?
• Quelles règles nationales s’appliqueront (paie, fiscalité, localisation des données) ?
• Que perd l’entreprise si la plateforme tombe pendant une heure ?

La croissance se prépare, elle ne se subit pas.

Chaque réponse se traduit par une contrainte. Un groupe de plusieurs sociétés doit être multi-tenant dès le départ : l’ajouter ensuite oblige à reprendre chaque table et chaque requête. Un produit destiné à des utilisateurs arabophones doit prévoir l’affichage de droite à gauche dans ses fondations. Le rajouter après coup, c’est refaire tous les écrans.

Poser les frontières en premier

Nous repérons les parties du système qui devront un jour vivre seules, comme la facturation, la recherche ou les notifications, et nous traçons dès maintenant des frontières nettes autour d’elles, même si tout part en production sous la forme d’un seul service.

Concrètement, une frontière est une interface. Le reste du code s’appuie sur elle, sans rien savoir de l’implémentation qui se trouve derrière :

// a seam today, a service tomorrow
export interface Billing {
  charge(order: Order): Promise<Receipt>
}

Au début, l’implémentation tient en quelques fonctions dans la même base de code. Le jour où la facturation devient assez complexe pour justifier sa propre équipe, sa propre base de données ou son propre rythme de mise en production, elle peut migrer derrière la même interface sans que le reste de la plateforme s’en aperçoive.

Toute la différence entre anticiper et surdimensionner est là. Nous ne démarrons pas avec une douzaine de microservices, un bus de messages et trois bases de données. Nous démarrons avec une seule application bien structurée, dont les frontières sont déjà placées là où viendront les futurs services.

Le principe vaut aussi pour les intégrations. Chaque système externe, du logiciel comptable au fournisseur d’identité, passe par un adaptateur. Changer de fournisseur devient alors une modification localisée, et non une migration.

Mesurer avant de grandir

Chaque plateforme que nous mettons en ligne est supervisée dès le premier jour. Quand vient le moment de monter en charge, la décision s’appuie donc sur des données et non sur des impressions.

Trois éléments sont en place avant même que le premier vrai utilisateur se connecte :

• Des métriques sur les temps de réponse, les taux d’erreur et les actions métier qui comptent (demandes validées, factures émises).
• Des journaux consultables par organisation, par utilisateur et par requête, pour remonter chaque problème jusqu’à sa cause.
• Des alertes qui réveillent quelqu’un quand un seuil est franchi, avant que les clients s’en rendent compte.

Avec ces outils, monter en charge devient une suite de petites décisions éclairées : cette requête a besoin d’un index, ce rapport devrait tourner en tâche de fond, ce client mérite sa propre base de données. Sans eux, on navigue à vue, et ce genre de pari finit souvent par coûter cher.

En pratique

Pour une plateforme de gestion classique, le résultat est volontairement sans surprise : une seule application, multi-tenant dès la première table, avec authentification unique, piste d’audit côté serveur, frontières internes nettes, tests automatisés et supervision. Rien d’exotique, et rien qu’il faudra jeter quand l’entreprise aura grandi.

L’ambition se loge dans le plan, pas dans la complexité. Envie que nous regardions votre cible et que nous vous disions quelles décisions comptent dès aujourd’hui ? Réservez un appel.