Le rafraîchissement est une décision de conception, pas une fonctionnalité
Chaque source publie selon ses propres modalités. Certaines exposent une interface consultable à la demande, d'autres produisent un fichier chaque nuit, et d'autres exigent qu'une personne exporte un rapport. Une architecture vivante consigne ce que chaque source peut réellement faire et conçoit le processus en fonction de cette réalité.
C'est pourquoi une promesse générale de mises à jour horaires n'est pas crédible. Ce qui l'est, c'est d'afficher l'âge de chaque chiffre dans l'interface et de définir, par source, ce qu'est un âge acceptable.
Le rapprochement devrait révéler les désaccords
Lorsque deux sources se contredisent, la mauvaise réponse consiste à en choisir une. Une architecture vivante conserve les deux valeurs, consigne leur provenance respective et achemine l'écart vers une personne pouvant le résoudre.
Avec le temps, le schéma des écarts devient lui-même une information. Si une source est systématiquement en retard ou systématiquement erronée dans le même champ, il s'agit d'un problème d'intégration à corriger plutôt que d'une tâche de rapprochement à automatiser.
Les permissions voyagent avec les données
Les règles d'accès ne peuvent s'appliquer uniquement à l'écran. Si une étape de recherche peut lire un document, alors une réponse générée à partir de ce document peut en révéler le contenu à quelqu'un qui ne devrait pas le voir. Les permissions doivent être appliquées au moment de la recherche, pas seulement à la présentation.
Cette contrainte façonne le modèle de données. Les entités, les portefeuilles de clientèle et la propriété des dossiers ne sont pas de simples dimensions de reporting; ce sont les frontières que le système fait respecter.
Les dates de source doivent apparaître à l'écran
Un chiffre sans date est une affirmation. Un chiffre avec une source et une date est une preuve. Afficher les deux, y compris un état explicite d'obsolescence lorsqu'une source n'a pas été mise à jour, est l'un des moyens les moins coûteux de rendre un système digne de confiance.
Rétroaction et contrôle des changements
Les corrections des réviseurs sont précieuses, mais elles ne devraient pas modifier le système silencieusement. Une correction devient un changement proposé : consigné, évalué au regard des mesures d'acceptation, approuvé par un responsable nommé et publié comme une version pouvant être annulée.
C'est la distinction la plus importante. La fraîcheur des données signifie que le système observe l'information actuelle. Le réentraînement d'un modèle signifie que le comportement du système change. Le premier devrait être routinier et continu. Le second est une mise en production contrôlée, avec ses propres essais et approbations, et ne devrait jamais survenir comme un effet secondaire de l'utilisation quotidienne.
Le retrait fait partie du cycle de vie
Les processus survivent parfois à leur utilité. Une source est remplacée, une réglementation change, une équipe se réorganise. Une architecture vivante prévoit un moyen de retirer une composante : la retirer du processus, conserver ses dossiers selon les règles de conservation convenues et supprimer l'accès qui n'a plus de raison d'être.
Un système qui ne peut que croître n'est pas vivant. Il s'accumule.