Notre
approche

Une méthode ne se juge pas à ses étapes. Elle se juge aux décisions qu’elle rend possibles.

Cette page explique notre manière de décider. Le reste en découle.

02

Le coût
du moment

Une décision ne coûte pas le même prix selon le moment où elle est prise.

Tant qu’une décision d’architecture reste une hypothèse, elle ne coûte qu’un peu d’attention. Dès qu’elle devient un existant — du code déployé, des équipes formées, des données migrées — elle coûte un projet.

Entre les deux, il s’écoule rarement plus de quelques semaines. La plupart des entreprises ne se sont pas trompées de solution. Elles ont décidé trop tard.

Le prix d’une décision ne dépend pas de sa difficulté.
Il dépend de son moment.

03

La méthode
en une vue

Quatre étapes, ordonnées par le risque.

01 Comprendre

Qu’est-ce qui ralentit réellement l’entreprise ?
02 Imaginer

Quelles options avons-nous, et qu’est-ce que chacune nous ferme ?
03 Construire

Quel est le prochain palier, et rien de plus ?
04 Faire vivre

Que se passe-t-il si nous partons demain ?

Transmission

Cet ordre n’est pas une convention de métier. C’est un ordre de risque décroissant : chaque étape réduit l’incertitude de la suivante. Comprendre coûte des jours. Reconstruire coûte des trimestres.

Une seule chose traverse les quatre étapes, et c’est elle que vous gardez après notre départ : la décision écrite, avec son contexte, ses options écartées et son compromis assumé.

04

Étape un
Comprendre

Une bonne architecture ne corrige jamais une mauvaise compréhension.

La question: Qu’est-ce qui ralentit réellement l’entreprise ? Presque jamais ce qui est cité en premier.
Ce que nous cherchons: L’écart entre l’organisation réelle et le système censé la servir. C’est dans cet écart que se logent les blocages.
L’arbitrage: Cartographier l’existant plutôt que recueillir des besoins. Les besoins exprimés décrivent des symptômes ; les flux décrivent la cause.
Ce que nous refusons: Proposer une solution avant d’avoir vu le système fonctionner un jour ouvré complet.
Ce que vous obtenez: Cartographie des flux, inventaire des dépendances, liste des points de rupture, et l’ordre dans lequel les traiter.

C’est la seule étape qu’on ne peut pas rattraper plus tard.

05

Étape deux
Imaginer

Une décision dont on ignore les alternatives n’est pas une décision.

La question: Quelles options avons-nous, et qu’est-ce que chacune nous interdit pour la suite ?
Ce que nous cherchons: Le plus petit changement qui débloque le plus grand nombre de décisions futures.
L’arbitrage: Trois trajectoires étudiées sérieusement. Une retenue. Deux écrites, avec la raison précise de leur mise à l’écart.
Ce que nous refusons: La solution élégante qui suppose une équipe que vous n’avez pas, ou un budget que vous n’aurez pas.
Ce que vous obtenez: Une note d’architecture, des options chiffrées en mois, et une décision motivée au format ADR.

Une décision ne vaut que par les alternatives qu’elle écarte. Vous devez pouvoir contester notre raisonnement, pas seulement notre conclusion.

06

Étape trois
Construire

Nous construisons le prochain palier. Pas celui d’après.

La question: Quel est le prochain palier de l’entreprise, et qu’est-ce qui n’a pas besoin d’exister avant ?
Ce que nous cherchons: Une architecture que vos équipes peuvent tenir sans nous, dès la mise en production.
L’arbitrage: Livrer par paliers utilisables plutôt que par grands lots. Chaque palier doit pouvoir être arrêté sans perte.
Ce que nous refusons: Anticiper un besoin d’après-demain au prix de la lisibilité d’aujourd’hui. Et l’inverse.
Ce que vous obtenez: Un système en production, sa documentation d’exploitation, ses tests, son observabilité.

Une architecture se juge le lendemain de sa livraison.

07

Étape quatre
Faire vivre

Nous préparons notre départ dès le premier jour.

La question: Que se passe-t-il si nous partons demain matin, sans préavis ?
Ce que nous cherchons: Le moment précis où notre présence n’ajoute plus rien. Puis nous le disons.
L’arbitrage: Transmettre les décisions, pas seulement le code. Former pendant la mission, jamais dans les deux dernières semaines.
Ce que nous refusons: Toute dépendance qui nous rendrait nécessaires par défaut : outil maison non documenté, accès exclusif, savoir non écrit.
Ce que vous obtenez: Un registre de décisions à jour, une équipe qui sait l’alimenter, et le plan du palier suivant.

Une mission réussie prépare notre départ dès le premier jour.

08

Anatomie
d’une décision

Voici à quoi ressemble une décision chez nous.

Voici une décision réelle, telle qu’elle a été écrite.

Contexte: Plateforme e-commerce, quarante personnes. Le back-office ne suit plus les volumes de pointe. Trois équipes attendent la même migration depuis dix-huit mois. Aucune n’ose commencer, parce qu’aucune ne sait où s’arrête son périmètre.
Options envisagées: A Réécrire la plateforme. 14 mois Ferme toute évolution produit pendant la durée. Aucun retour avant la fin.

B Extraire le domaine commande. 4 mois Ne ferme rien de structurant. Ajoute une frontière à maintenir.

C Optimiser l’existant. 6 semaines Ferme le palier suivant. Le blocage revient sous douze mois, plus cher.
Décision: Option B. Extraire le domaine commande derrière une frontière explicite, sans toucher au reste.
Compromis assumé: Une frontière de plus à maintenir, et six mois de cohérence différée entre deux systèmes. Nous le disons avant de commencer, pas au moment où cela se voit.
À trois ans: Le socle commande peut être remplacé seul. Si la réécriture globale arrive un jour, elle ne sera plus un événement — seulement une suite de paliers.

A	Réécrire la plateforme.	14 mois	Ferme toute évolution produit pendant la durée. Aucun retour avant la fin.
B	Extraire le domaine commande.	4 mois	Ne ferme rien de structurant. Ajoute une frontière à maintenir.
C	Optimiser l’existant.	6 semaines	Ferme le palier suivant. Le blocage revient sous douze mois, plus cher.

Le code évoluera. Cette décision restera. C’est ce document, et non le code, qui permettra à quelqu’un d’autre de reprendre le sujet dans deux ans.

09

Ce que
nous refusons

Une méthode se reconnaît à ce qu’elle interdit.

R—01

Livrer un système que le client ne sait pas expliquer.

S’il faut nous appeler pour comprendre une décision, la décision est mal écrite.
R—02

Choisir une technologie avant d’avoir compris le métier.

L’ordre inverse produit des architectures défendables et inutiles.
R—03

Construire pour un palier que l’entreprise n’atteindra peut-être jamais.

La sur-ingénierie est une dette payée d’avance, sur un besoin hypothétique.
R—04

Taire un compromis pour rendre une proposition plus séduisante.

Un compromis caché finit toujours par se présenter, au pire moment.
R—05

Exécuter une décision que nous jugeons mauvaise sans l’avoir dite.

Nous pouvons l’appliquer après discussion. Jamais sans.
R—06

Créer une dépendance qui nous rendrait indispensables.

Un prestataire irremplaçable est un risque, pas un partenaire.

10

La fin
de mission

Comment nous savons que c’est réussi.

01

Les équipes expliquent leur système.

Sans nous, sans schéma improvisé, à un nouvel arrivant.
02

Les décisions se prennent sans nous.

Le registre est vivant : quelqu’un d’autre y écrit.
03

Le palier suivant est identifié.

Et personne ne redoute d’y arriver.
04

La technologie cesse d’occuper les conversations.

Le comité de direction parle à nouveau de métier.

11

Prochaine
étape

La prochaine décision structurante, vous allez la prendre de toute façon. Autant savoir ce qu’elle rendra possible.

Parlons de la prochaine décision qui compte