Après deux ans chez HLC comme architecte de solutions, je passe beaucoup de temps sur les frontières entre systèmes. Une API, un événement, une connexion utilisateur et une mise à jour AX sont quatre contrats. Chacun porte une identité, une version, un résultat et un cas où l’autre côté ne répond pas.

Le diagramme doit donc montrer autre chose que des flèches. Je veux savoir qui appelle, quelle donnée fait autorité, combien de temps on attend, comment on reprend et qui reçoit l’alerte.

Une grille commune pour quatre mécanismes

Pour une API de commande :

1. authentifier client et scope;
2. valider schéma et règle;
3. appliquer avec clé idempotente;
4. retourner version et corrélation;
5. surveiller erreur, latence et quota.

Pour le MFA, le cycle inclut inscription, preuve, révocation et récupération. Pour Kubernetes, état désiré, probe, remplacement et sauvegarde d’etcd. Pour AX, artefact, configuration, test métier et compensation. Les technologies diffèrent, mais chaque boucle doit rendre l’état visible.

L’année Tay ajoute une frontière plus étrange : du texte public vers un comportement automatisé. Une entrée non fiable ne peut pas devenir directement un apprentissage ou une action. Modération, jeu d’évaluation, version et bouton d’arrêt sont des composants d’architecture.

La reprise révèle le vrai propriétaire

Une file en erreur sans personne assignée n’est pas résiliente. Un compte bloqué sans procédure solide crée un contournement. Un Pod recréé sans donnée récupérable revient vide. Une version AX retournée après l’envoi de factures ne corrige pas le métier. Le propriétaire doit connaître le résultat attendu, pas seulement l’outil.

Je conserverais pour chaque frontière un petit dossier opérationnel : contrat, exemples, dépendances, niveaux de service, erreurs, runbook et historique de version. Les tests injectent timeout, doublon, message hors ordre, rôle retiré et secret expiré. Les signaux confirment que le repli a eu lieu.

La sécurité devient une identité de machine autant qu’une identité humaine. Les comptes de service ont des permissions limitées, les certificats et secrets tournent, les actions administratives sont auditées. Un réseau interne ne transforme pas automatiquement les appels en confiance.

Donner un identifiant à la décision humaine

Une frontière se termine parfois par une approbation. Cette décision devrait porter l’objet, la version vue, le rôle, la règle et l’heure. Le système refuse une approbation sur une version dépassée et garde le commentaire séparé des données structurées. Si le workflow est indisponible, la demande reste à décider; un courriel ne devient pas la source officielle. Une délégation possède une période et un audit. Ces détails relient la responsabilité humaine aux mêmes mécanismes de concurrence et de reprise que les services. Ils empêchent qu’une API parfaitement traçable perde son fil au moment précis où une personne tranche l’exception.

Pour 2017, ma pratique sera de prendre une opération importante et de tracer son identifiant de l’écran jusqu’au grand livre. Si une équipe ne peut pas expliquer l’état à une frontière, on ajoute un reçu, une version ou une corrélation avant d’ajouter une nouvelle plateforme. Le contrat devient utile quand il survit au premier déraillement.