Une discussion de budget m’a ramené à un principe : couper le même pourcentage partout n’est pas neutre. Retirer une animation et retirer une sauvegarde coûtent peut-être le même montant aujourd’hui; les conséquences et la réversibilité ne se comparent pas.

L’architecture sous contrainte doit protéger les décisions longues à refaire : modèle de donnée, identité, contrat externe, sécurité et reprise. Les éléments de confort peuvent être reportés si leur absence est visible et acceptable.

Classer le risque avec un exemple

Pour un portail de commandes, je garderais une matrice :

1. authentification forte — impact élevé, difficile à ajouter après fuite;
2. idempotence de commande — impact financier, structure le contrat;
3. sauvegarde restaurée — impact élevé, preuve avant production;
4. cache avancé — performance, ajout possible après mesure;
5. rapport secondaire — valeur limitée, report explicite;
6. animation du panier — confort, réversible.

Chaque coupe nomme probabilité, impact, détectabilité, contournement, propriétaire et date de revue. « Accepté » ne veut pas dire oublié. Une dette possède une condition de remboursement, par exemple lorsque le volume dépasse mille commandes par jour.

Un prototype peut utiliser une file simple et une seule zone, mais il ne doit pas contenir de vraies données si ses contrôles ne suivent pas. Réduire le périmètre est souvent plus sûr que réduire transversalement la qualité : une famille de produits complète plutôt que tout le catalogue à moitié.

Garder les preuves minimales

Même avec peu de moyens, je veux source versionnée, build reproductible, logs structurés, sauvegarde et test de reprise. Ces éléments réduisent le coût d’incident. Une plateforme gérée peut remplacer de l’exploitation maison, à condition de comprendre limites, export et facture.

La sécurité suit le risque. Les comptes privilégiés, secrets, données client et accès externes ne passent pas en « phase 2 ». En revanche, un tableau de bord sophistiqué peut attendre si une alerte simple et un runbook couvrent le besoin.

Je chiffrerais aussi le coût de ne rien faire : heures manuelles, incident attendu, dépendance à une personne et pénalité de changement tardif. Le budget devient une comparaison d’options, pas un veto abstrait de l’architecture.

Chiffrer le risque résiduel sans fausse précision

Je peux estimer fréquence, impact maximal, contrôles et exposition, puis classer les risques. Multiplier deux nombres inventés au dollar près donne une précision trompeuse. Je préférerais des fourchettes et trois scénarios : attendu, sérieux et extrême. Pour chacun, le dossier indique temps d’arrêt, données perdues, clients touchés et coût de reprise. Une simulation de Monte-Carlo peut aider lorsque les entrées sont fondées, mais la conversation reste plus importante que le score. Le décideur signe la fourchette et les hypothèses. Cette méthode compare les coupes sans prétendre connaître la date du prochain incident.

À la fin, je publierais une page : portée livrée, risques acceptés, contrôles présents, limites et déclencheurs. Puis je testerais le pire risque conservé. L’architecture n’a pas besoin d’être chère; elle doit empêcher qu’une économie locale se déguise en garantie que le système ne possède pas.