Information et décision : deux couches

Pendant un temps, l'architecture traitait la création d'un document comme la fin d'un processus.

C'était une simplification utile. Elle était aussi erronée.

Un document peut enregistrer, communiquer ou prouver quelque chose. La conséquence — approuver, payer, publier ou rejeter — appartient au processus qui l'utilise. Confondre les deux donne l'impression qu'un système est achevé avant même que la décision importante ait réellement eu lieu.

La différence paraît minime. En pratique, elle change la place de la validation, de l'autorité, du jugement humain et de la reprise après un échec.

Là où le modèle a échoué

Le problème est devenu visible dans une intégration comptable. La séquence prévue était prudente : préparer l'information dans un système, la réviser, puis seulement autoriser une action externe ayant une conséquence fiscale.

La documentation publique de l'interface ne permettait pas initialement de prouver qu'une véritable pause avant finalisation était possible. Plusieurs implémentations semblaient envisageables, mais aucune n'était vérifiée.

Cette incertitude a défini la première frontière de production. Le système pouvait charger les données locales faisant autorité, vérifier les permissions et la cohérence, préparer la référence externe et indiquer si l'information était prête. Il ne pouvait pas écrire dans le système externe.

Il ne s'agissait pas d'une automatisation inachevée déguisée en architecture. C'était une frontière explicite : avancer avec ce qui était connu et s'arrêter là où le contrat externe restait incertain.

L'erreur est venue ensuite. J'ai transformé un contrôle conçu pour une intégration à conséquences en modèle général pour tous les documents.

Le modèle se transposait mal à d'autres cas. Un contrat, un rapport opérationnel, un relevé importé et une note interne sont tous des documents, mais ils ne créent pas les mêmes obligations et n'exigent pas les mêmes contrôles.

Le cas constituait une preuve utile. Il ne constituait pas la catégorie.

Deux responsabilités, pas un seul cycle de vie

Le modèle révisé sépare deux responsabilités.

La première concerne l'information elle-même :

De quel objet s'agit-il ?
Quelle est la version actuelle ?
D'où vient l'information ?
Qui peut y accéder ou la modifier ?
Combien de temps doit-elle être conservée ?

La seconde concerne la décision qui l'utilise :

Qui détient l'autorité pour avancer ?
Que faut-il vérifier au préalable ?
Quel événement crée la conséquence réelle ?
Que se passe-t-il si le résultat est rejeté ou reste incertain ?
Comment confirmer ce qu'un système externe a réellement fait ?

Les deux couches sont liées, mais n'avancent pas ensemble. Un contrat peut atteindre sa quatrième version alors que sa révision juridique reste ouverte. Un rapport peut être définitif comme document tandis que la décision opérationnelle qui s'appuie sur lui reste en attente. Un PDF peut préserver la preuve d'une approbation sans être l'approbation elle-même.

Cette séparation est cohérente avec les normes établies de gestion documentaire et de processus. ISO 15489 se concentre sur la création et la gestion des documents d'activité. W3C PROV distingue information, activité et responsabilité. BPMN sépare les données utilisées par un processus des activités et décisions qui composent ce processus.

Les normes valident la distinction. Elles n'ont pas besoin de dominer la conception.

Ce qui a changé dans l'architecture

Le premier modèle semblait rassurant par sa linéarité : l'information entrait, passait la validation, recevait une approbation et produisait un document final.

Le travail réel était moins ordonné. Une décision pouvait attendre, échouer, revenir pour correction ou dépendre d'une réponse externe qui n'arrivait jamais. Le document pouvait changer sans rouvrir la décision ; la décision pouvait changer sans produire de nouveau fichier.

L'architecture révisée commence donc par trois questions :

Quelle information doit rester fiable ?
Quelle décision crée la conséquence, et qui en est responsable ?
Quelles preuves et quelle reprise sont nécessaires lorsque le résultat est incertain ?

Les contrôles découlent des réponses. Une double approbation peut être justifiée pour un risque et inutile dans un autre contexte. Une signature peut prouver qui a signé sans démontrer que le contenu est exact. Une nouvelle tentative automatique peut être sûre lorsque le service externe empêche les doublons et dangereuse lorsqu'il ne le fait pas. Conserver toutes les versions peut faciliter un audit tout en contredisant une obligation légitime de suppression.

Le contrôle ne définit pas l'architecture. L'architecture explique pourquoi ce contrôle existe et où il cesse d'être utile.

Le changement professionnel

Les versions antérieures de mon travail devenaient souvent plus élaborées à mesure que l'incertitude augmentait. Davantage d'états, de vérifications et de composants donnaient à la conception une apparence plus sûre.

Ce cas a changé cet instinct. Lorsqu'une hypothèse ne peut pas être vérifiée, ajouter des mécanismes autour d'elle ne la rend pas vraie. Une frontière plus petite peut constituer la conception la plus responsable.

C'est cette évolution qu'il importe de montrer : non pas une suite de fonctionnalités livrées, mais un changement dans la manière de répartir la responsabilité. L'information doit rester compréhensible. Les décisions doivent avoir des responsables. Les conséquences doivent être observables. L'incertitude doit arrêter le système au bon endroit.

La maturité architecturale ne se voit pas au nombre de cases dans un schéma. Elle se voit à la précision de leurs frontières.

Sources

TOConline, Documents de vente — API actuelle — https://api-docs.toconline.pt/apis/vendas/documentos-de-venda (consulté le 14 septembre 2026).
TOConline, Documents de vente — Versions antérieures — https://api-docs.toconline.pt/apis/versoes-anteriores/vendas/documentos-de-venda (consulté le 14 septembre 2026).
ISO, ISO 15489-1:2016 — Records management: Concepts and principles — https://www.iso.org/standard/62542.html (version actuelle confirmée par l'ISO en 2021).
W3C, PROV-O: The PROV Ontology — https://www.w3.org/TR/prov-o/ (Recommandation du W3C, 2013).
Object Management Group, Business Process Model and Notation 2.0.2 — https://www.omg.org/spec/BPMN/2.0.2/PDF (2014).
IETF, RFC 9110 — HTTP Semantics, §9.2.2 Idempotent Methods — https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2 (2022).
Union européenne, Règlement (UE) 2016/679 — RGPD, article 5(1)(e) — https://eur-lex.europa.eu/eli/reg/2016/679/oj.