Ma première année complète comme directeur TI commence avec un mot qu’on n’aime pas beaucoup en architecture : non. On ne peut pas maximiser en même temps résilience, vitesse, flexibilité et réduction des coûts. Un compromis devient sain lorsqu’il est lié à une hypothèse mesurable et à une décision de sortie.

Prenons un traitement de commandes qui roule une fois par nuit. À 5 000 lignes, un fichier CSV et un job SQL peuvent être le meilleur rapport valeur/coût. Construire immédiatement une plateforme d’événements redondante ajouterait des services, des compétences et des alertes. Mais le fichier repose sur des limites : volume, fenêtre nocturne, reprise manuelle et tolérance à des données vieilles de plusieurs heures.

Je consignerais la décision dans une fiche courte :

Décision       ADR-2022-014
Choix          import CSV nocturne, un seul worker
Hypothèse      <= 10 000 lignes/jour, résultat requis avant 6 h
Risque         retard ou reprise manuelle après panne
Contrôles      empreinte du fichier, lot idempotent, alerte avant 5 h
Déclencheur    > 45 min trois jours ou > 8 000 lignes/jour
Responsable    Opérations TI
Révision       chaque trimestre et au déclenchement

Le mécanisme de reprise fait partie du compromis. Le job crée un LotId, valide le fichier, écrit en staging, puis commet le lot dans une transaction. Une contrainte unique empêche de charger deux fois le même fichier. Si la panne arrive après le commit mais avant l’accusé, le prochain essai retrouve le lot terminé au lieu de doubler les commandes.

fichier → checksum → staging → validation → transaction → lot terminé
                    ↘ rejets datés          ↘ reprise par LotId

Je calcule aussi le coût total, pas seulement la licence. L’option actuelle demande deux heures manuelles par semaine à 70 $ et provoque quatre interruptions annuelles de trois heures pour cinq personnes. Son coût approximatif dépasse 2 × 52 × 70 + 4 × 3 × 5 × 70 = 11 480 $, avant l’impact client. Une automatisation de 30 000 $ ne devient pas automatiquement rentable; le calcul donne au moins un ordre de grandeur et les variables à suivre.

Une dette avec un signal, pas une promesse

« On reverra ça plus tard » n’est pas un plan. Le seuil de 45 minutes peut être mesuré. La fin de support d’un produit possède une date. Un taux d’erreur, un volume, un temps de restauration ou le départ d’une compétence unique sont des déclencheurs exploitables. Le registre doit produire une alerte ou entrer dans une revue normale, pas dépendre de la mémoire de l’architecte.

Le contrôle suit le risque. Garder une étape manuelle peut protéger une décision irréversible, mais il faut mesurer son temps et ses erreurs. Reporter un deuxième site est raisonnable si le RTO accepte une journée, les backups sont hors du site et un test prouve la restauration. Économiser sur la copie isolée tout en promettant quatre heures serait une contradiction, pas un compromis.

Les économies faciles à justifier méritent le même examen. Un outil de sécurité sans flux d’alerte, une sauvegarde jamais restaurée ou une capacité redondante qui partage la même identité réduit peu le risque. J’exige une preuve opérationnelle : alerte prise en charge, bascule chronométrée, restauration avec transaction métier.

Je suis capable de vivre avec une architecture imparfaite. Ma pratique sera d’accompagner chaque limite volontaire de son hypothèse, son propriétaire, son contrôle et son déclencheur. Quand le seuil arrive, la discussion ne repart pas de zéro et l’économie ne peut plus se cacher sous le mot « temporaire ».