Notre approche
Construire pour durer dans un monde imprévisible.
Nous ne cherchons pas l'architecture parfaite.
Nous concevons des systèmes capables d'évoluer, d'absorber les imprévus et de continuer à rendre leur service lorsque leur environnement change.
Parce qu'un logiciel durable n'est pas seulement performant : il est robuste, adaptable et compréhensible.
Le bon niveau, pas le maximum
Ne pas confondre performance et robustesse
Un seul chemin critique
Peu de latitude quand elles changent.
Des marges et des alternatives
De la latitude pour absorber l'imprévu.
Optimiser est utile pour supprimer du gaspillage : une requête inutilement lente, une consommation excessive de ressources ou des traitements superflus méritent d'être corrigés.
La performance maximale peut aussi supprimer des marges utiles. Nous visons le bon niveau de performance, puis consacrons les ressources restantes à la résilience, à l'observabilité, à la maintenabilité ou à l'évolution.
« Optimiser ce qui gaspille.
Préserver ce qui donne de la marge. »
Les réflexions d'Olivier Hamant sur la robustesse nourrissent cette démarche. Nous les traduisons en choix d'ingénierie adaptés au contexte de chaque entreprise.
De l'idée aux choix techniques
Cinq principes concrets
Une architecture logicielle qui préserve la capacité d'adaptation, sans ajouter de complexité inutile.
Garder plusieurs chemins possibles
Une dépendance critique ne devrait pas toujours être un point de défaillance unique. Pour un service essentiel, une alternative, un mode dégradé ou une redondance peut être plus utile que l'efficacité absolue.
Authentification, paiement, stockage, service tiers : la criticité détermine le besoin. Pas question de tout doubler : la redondance ajoute aussi de la complexité.
Conserver des portes de sortie
Ports & Adapters, contrats explicites et séparation du domaine limitent les dépendances irréversibles. L'infrastructure peut évoluer sans réécrire tout le système.
Il ne s'agit pas de changer de base tous les six mois, mais d'éviter qu'une décision technique contamine tout le système.
Préparer avant d'avoir besoin
La veille technologique n'est pas une course à la nouveauté. De petits proof of concept / POC permettent de vérifier une hypothèse, comprendre une technologie ou préparer une migration avant l'urgence.
- Explorer
- Expérimenter
- Comprendre
- Attendre
- Basculer
si nécessaire
Expérimenter ne signifie pas adopter. Un POC sert d'abord à apprendre et à réduire l'incertitude.
Mesurer avant d'optimiser
- Latence
- 120 ms
- CPU
- 42 %
- Mémoire
- 58 %
- Erreurs
- 0,2 %
Comprendre → décider → agir
CPU, mémoire, latence, Core Web Vitals et traces distribuées éclairent le comportement réel du système. Un indicateur n'est jamais une finalité.
Performance et observabilité servent à repérer les gaspillages et à concentrer l'effort là où il crée de la valeur.
Concevoir avec l'imprévu
Un fournisseur disparaît, une API change, la charge augmente, une technologie vieillit, un besoin métier inattendu apparaît. L'architecture n'évolue jamais exactement comme prévu.
Modularité, découplage, observabilité, documentation et simplicité : des marges de manœuvre pour rendre le changement moins coûteux.
Un exemple concret : la performance
Être performant, oui.
À tout prix, non.
2 secondes → 80 ms
Optimiser
Une meilleure requête ou un index rend le même résultat en 80 ms au lieu de deux secondes. L'expérience s'améliore et les ressources consommées diminuent.
Nous optimisons.
1,1 seconde → 900 ms
Arbitrer
Gagner 200 ms exige des semaines de travail et complexifie l'architecture, alors que le système manque d'observabilité et de mécanismes de repli.
Nous arbitrons.
50 % de ressources inutilisées
Conserver une marge
Plutôt que de fonctionner à 90 % de ses capacités, un service à 50 ou 60 % peut absorber un pic de charge ou la perte d'une instance.
Nous gardons volontairement de la marge.
Ni tout doubler, ni tout prévoir
La robustesse reste une affaire de compromis.
Doubler chaque composant, multiplier les abstractions ou prévoir toutes les situations possibles aurait l'effet inverse : davantage de complexité et de nouvelles sources de défaillance.
Notre travail consiste à identifier ce qui mérite réellement une marge de sécurité. Criticité métier, coût d'une panne, probabilité d'un changement et complexité induite guident nos choix.
La robustesse logicielle et la sobriété numérique se rejoignent : employer les ressources là où elles sont utiles, sans surdimensionner tout le système.
Du contexte à l'évolution
Notre manière de travailler
Comprendre
Le métier, le système existant, ses contraintes et ses véritables points de fragilité.
Observer
Mesurer avant de conclure : métriques, logs, traces, tests et retours des équipes.
Expérimenter
Tester les hypothèses à petite échelle avant d'engager une transformation importante.
Faire évoluer
Améliorer progressivement, conserver des alternatives et pouvoir revenir sur certaines décisions.
Une architecture durable
Construire aujourd'hui
en laissant un maximum d'options ouvertes.
Nous ne pouvons pas prévoir précisément les technologies, les usages ou les contraintes de demain. Nous pouvons construire des systèmes suffisamment simples, observables et adaptables pour y faire face.
C'est cette capacité à évoluer que nous appelons une architecture durable.
Parler de votre architecture