En décembre, mon passage chez Nurun se termine et je commence comme architecte de solutions chez HLC, dans le secteur du vélo. Je change de domaine, mais les mêmes frontières me suivent : identité, données, déploiement et reprise entre plusieurs plateformes.

Les conteneurs rendent l’artefact plus reproductible. Le SSO centralise la preuve d’identité. Le cloud remplace les instances. Dynamics AX relie les opérations. Aucun de ces mécanismes ne travaille seul. L’année m’a appris à lire les flèches comme des contrats.

Quatre flux qui demandent une preuve

Pour une livraison conteneurisée :

source → build → image signée → registre → instance → métriques

Pour une connexion :

navigateur → CAS → ticket → portail → rôle local

Pour une commande ERP :

vente → réservation → expédition → facture → grand livre

Pour une donnée maître :

proposition → validation → source d’autorité → événement → copies

Dans chaque cas, je poserais les mêmes étapes :

1. identifier l’objet et sa version;
2. authentifier l’émetteur;
3. valider le contrat et l’autorisation;
4. rendre le changement durable;
5. confirmer précisément le résultat;
6. permettre reprise ou compensation;
7. garder assez de traces pour réconcilier.

Une flèche sans timeout peut bloquer; sans idempotence, doubler; sans propriétaire, rester en erreur. Le système de destination peut être sain et la frontière quand même cassée.

L’exploitation doit entrer dans le dessin

Je veux voir les files, certificats, sauvegardes, journaux et comptes de service sur l’architecture. Un conteneur remplaçable ne protège pas sa base. Un SSO disponible ne corrige pas un mauvais rôle. Deux instances cloud ne récupèrent pas une suppression logique. Un ERP cohérent peut appliquer une règle fausse à toute l’entreprise.

Le changement chez HLC va me placer devant plusieurs écosystèmes à rapprocher. Avant de choisir une grande cible, je construirais un inventaire des autorités : quel système possède produit, client, stock, prix et facture? Puis je tracerais un exemple réel, avec ses identifiants et états, entre les systèmes.

Les pannes contrôlées donnent une meilleure architecture review que les adjectifs. Couper l’identité, renvoyer un message, tuer une instance et restaurer un document montrent les hypothèses. Les résultats deviennent des décisions de conception et des runbooks.

Tenir un registre des dépendances vraiment critiques

Je ne veux pas un inventaire de chaque librairie dans la revue d’architecture, mais une carte des composants dont la panne arrête plusieurs parcours : annuaire, DNS, bus, ERP, registre et clés. Pour chacun, on note consommateurs, objectif de service, mode dégradé et exercice de reprise. Une modification de certificat ou de contrat déclenche un avis aux propriétaires connus. Les métriques permettent de vérifier si le risque se concentre encore. Cette carte limite l’effet de surprise lorsque deux systèmes prétendument indépendants utilisent la même base ou le même compte. Elle donne aussi un ordre de restauration fondé sur les parcours plutôt que sur la taille des serveurs.

Ma pratique pour 2015 sera donc de donner à chaque frontière un contrat visible : schéma, version, identité, limite de temps, reprise, métrique et responsable. Les boîtes vont sûrement changer. Une bonne frontière permet de les changer sans perdre le fil des opérations.