Nous savons construire des logiciels.

Chaque jour, des milliers de développeurs conçoivent des applications capables de traiter des volumes considérables d'informations, d'automatiser des tâches complexes et de relier des systèmes toujours plus nombreux. Les outils, les langages et les infrastructures n'ont jamais été aussi puissants.

Pourtant, un paradoxe apparaît presque systématiquement.

Plus un système grandit, plus il devient difficile de comprendre ce qu'il est réellement.

Les premières versions sont généralement simples. L'architecture est claire, les responsabilités sont bien identifiées, les décisions sont encore présentes dans la mémoire de leurs auteurs. Chaque évolution semble naturelle et chaque nouvelle fonctionnalité trouve facilement sa place.

Puis les années passent.

Une fonctionnalité en appelle une autre. Des contraintes nouvelles apparaissent. Des corrections deviennent nécessaires. De nouveaux collaborateurs rejoignent le projet tandis que d'autres le quittent. Des composants sont remplacés, d'autres réécrits, certains conservés uniquement parce que personne n'ose plus les modifier.

Le logiciel continue de fonctionner.

Mais il devient progressivement plus difficile à gouverner.

Cette difficulté n'est pas liée à la qualité des développeurs. Elle ne provient pas non plus d'un manque de méthodes ou d'outils. Elle est la conséquence naturelle d'une accumulation de décisions dont la logique finit par se disperser au fil du temps.

Le problème n'est plus seulement de savoir comment le système fonctionne.

Le problème est de comprendre pourquoi il est devenu ce qu'il est.

Pourquoi cette règle existe-t-elle ?

Pourquoi cette transformation est-elle réalisée ici plutôt qu'ailleurs ?

Pourquoi cette information est-elle calculée plusieurs fois ?

Pourquoi deux composants semblent-ils produire des résultats similaires sans être réellement identiques ?

À ces questions, les réponses deviennent souvent approximatives.

On invoque l'historique du projet, les contraintes d'une ancienne version, une dépendance oubliée ou simplement l'habitude. Peu à peu, la connaissance qui a permis de construire le système cesse d'être portée par l'architecture elle-même pour se réfugier dans la mémoire de quelques personnes.

Le logiciel continue d'exister.

La connaissance qui l'a construit, elle, disparaît progressivement.

En réalité, ce phénomène apparaît chaque fois qu'un système manipule une connaissance appelée à évoluer dans le temps.

Nous l'avons rencontrée dans des contextes très différents.

Dans le développement de plateformes logicielles.

Dans la conception d'outils d'investigation blockchain.

Dans la production de publications techniques.

Et, plus étonnamment encore, dans l'écriture de cet ouvrage.

À chaque fois, la même difficulté réapparaît.

La connaissance évolue.

Les transformations s'accumulent.

Les décisions se succèdent.

Mais leur cohérence globale devient de plus en plus difficile à démontrer.

C'est à ce moment qu'apparaît la véritable question.

Comment conserver la maîtrise d'un système dont la connaissance évolue en permanence ?

Comment s'assurer qu'une transformation produit exactement l'état attendu ?

Comment expliquer plusieurs années plus tard pourquoi une décision a été prise ?

Comment permettre à une autre personne de reprendre le projet sans devoir reconstruire mentalement toute son histoire ?

Ces questions relèvent de la gouvernance.

Non pas au sens administratif ou organisationnel du terme.

La gouvernance, telle que nous l'entendons dans cet ouvrage, est la capacité d'un système à rendre explicites les transformations qui produisent sa connaissance.

Un système gouvernable est un système dont chaque état peut être expliqué.

Chaque transformation peut être comprise.

Chaque résultat peut être reproduit.

Chaque décision peut être justifiée.

Cette idée est beaucoup plus générale qu'il n'y paraît.

Elle ne dépend ni d'un langage de programmation, ni d'un domaine d'application, ni d'une technologie particulière.

Elle concerne tout système dont la mission consiste à acquérir, structurer, transformer, enrichir, partager ou publier de la connaissance.

C'est précisément cette recherche qui nous a conduits, progressivement, vers une autre manière de concevoir les architectures logicielles.

Nous n'avons pas commencé par imaginer une nouvelle architecture.

Nous avons commencé par chercher comment préserver durablement la cohérence d'une connaissance en évolution.

Peu à peu, une intuition s'est imposée.

Et si un système n'était pas, avant tout, un ensemble de fonctionnalités ?

Et si la véritable nature d'un système résidait moins dans les fonctionnalités qu'il propose que dans les transformations de connaissance qu'il réalise ?

Cette intuition allait progressivement conduire à une nouvelle manière de concevoir les systèmes eux-mêmes.

Nous ne cherchions pas à inventer une nouvelle architecture.

À cette époque, notre objectif était beaucoup plus modeste : construire de meilleurs systèmes.

Comme beaucoup de développeurs, nous pensions que les difficultés rencontrées provenaient principalement des outils, des technologies ou des méthodes employées. Lorsqu'un problème apparaissait, nous cherchions naturellement une meilleure organisation du code, une nouvelle abstraction ou un composant plus adapté.

Ces solutions amélioraient souvent la situation.

Mais jamais durablement.

Quelques années plus tard, une difficulté comparable réapparaissait ailleurs, sous une autre forme.

Au début, cela ressemblait à une succession de problèmes indépendants.

Puis une première intuition est apparue.

Le phénomène ne dépendait ni du langage utilisé, ni du domaine d'application, ni de la taille du projet.

Nous retrouvions les mêmes difficultés dans des contextes très différents.

Dans le développement de plateformes logicielles.

Dans la conception d'outils d'investigation blockchain.

Dans la production de publications techniques.

Et même dans l'écriture de cet ouvrage.

Les technologies changeaient.

Les objectifs étaient différents.

Les équipes également.

Pourtant, les mêmes questions revenaient inlassablement.

Pourquoi devient-il si difficile d'expliquer un système qui semblait pourtant parfaitement compris lors de sa conception ?

Pourquoi certaines décisions paraissent-elles évidentes lorsqu'elles sont prises, puis deviennent presque impossibles à justifier quelques années plus tard ?

Pourquoi la connaissance d'un projet finit-elle toujours par s'éloigner progressivement de son architecture ?

Ces questions semblaient d'abord indépendantes.

Peu à peu, elles ont commencé à dessiner un même paysage.

Une autre intuition est alors apparue.

Les systèmes que nous construisions étaient généralement décrits à travers leurs composants, leurs fonctionnalités ou leurs objets.

Nous parlions des éléments qui les constituaient.

Beaucoup plus rarement de ce qui les faisait évoluer.

Or, un système vivant ne se résume jamais à une photographie de son état courant.

Il est avant tout le résultat d'une succession de décisions, de transformations et d'évolutions qui lui ont progressivement donné sa forme actuelle.

Autrement dit, ce qui importe n'est pas seulement ce qu'un système est devenu.

C'est la manière dont il le devient.

Cette idée était encore imprécise.

Elle ne constituait pas une théorie.

Elle ne remettait pas encore en cause les architectures existantes.

Elle introduisait simplement un changement de perspective.

Peut-être fallait-il cesser de considérer les systèmes comme des ensembles de composants.

Peut-être fallait-il commencer à les regarder comme des suites de transformations.

Cette intuition allait progressivement conduire à une manière entièrement nouvelle de penser les architectures.

Pendant longtemps, nous avons pensé que les difficultés provenaient principalement des outils que nous utilisions.

Lorsqu'un projet devenait difficile à maintenir, nous changions de framework.

Lorsque les performances diminuaient, nous optimisions les algorithmes.

Lorsque l'architecture devenait confuse, nous réorganisions les composants.

Chaque amélioration produisait des bénéfices réels.

Mais aucune ne semblait résoudre le problème de fond.

Peu à peu, une évidence s'est imposée.

Les outils n'étaient pas la cause de nos difficultés.

Ils n'en étaient que le support.

Le véritable problème résidait ailleurs.

Il résidait dans notre manière de concevoir les systèmes eux-mêmes.

Pendant des décennies, le développement logiciel s'est essentiellement attaché à décrire des structures.

Nous avons appris à modéliser des objets.

À organiser des composants.

À définir des interfaces.

À répartir des responsabilités.

Toutes ces approches ont profondément amélioré la qualité des logiciels.

Mais elles partageaient souvent une même caractéristique.

Elles décrivaient principalement ce qu'un système est.

Beaucoup plus rarement ce qu'il devient.

Or un système vivant n'est jamais figé.

Il évolue.

Chaque nouvelle fonctionnalité transforme son architecture.

Chaque décision modifie son état.

Chaque correction influence les évolutions futures.

Un système n'est donc pas seulement un ensemble de composants.

Il est l'histoire de toutes les transformations qui l'ont conduit jusqu'à son état actuel.

Cette différence de point de vue change profondément la manière d'aborder l'architecture.

Si l'on considère un système comme une collection d'objets, l'objectif principal devient leur organisation.

Si l'on considère un système comme une succession de transformations, la question devient tout autre.

Comment garantir que chaque transformation produit exactement l'état attendu ?

Comment démontrer qu'une transformation est correcte ?

Comment expliquer plusieurs années plus tard pourquoi elle existe encore ?

Comment préserver la cohérence de l'ensemble malgré l'accumulation des évolutions ?

Ces questions ne concernent plus les outils.

Elles concernent la nature même des systèmes que nous construisons.

Progressivement, une nouvelle idée s'est imposée.

L'unité fondamentale d'une architecture n'est peut-être pas le composant.

Ce n'est peut-être pas davantage l'objet, la fonction ou le service.

L'unité fondamentale pourrait être la transformation elle-même.

Une transformation possède un état d'entrée.

Elle applique des règles explicites.

Elle produit un nouvel état.

Elle peut être comprise.

Elle peut être reproduite.

Elle peut être validée.

Elle peut être remplacée sans remettre en cause l'ensemble du système.

À partir de ce moment, l'architecture n'est plus seulement une organisation de composants.

Elle devient l'organisation d'une succession de transformations maîtrisées.

Cette idée allait progressivement conduire à la formalisation de la State Transformation Architecture.

Aucune architecture nouvelle n'est née d'un seul raisonnement.

La State Transformation Architecture n'est pas apparue comme une théorie élaborée avant d'être appliquée.

Elle s'est construite progressivement, au fil des projets, en cherchant à répondre toujours à la même question :

Comment préserver durablement la cohérence d'une connaissance qui évolue ?

Pendant longtemps, nous avons tenté d'améliorer les systèmes existants.

Nous avons affiné les modèles.

Réorganisé les composants.

Introduit de nouvelles abstractions.

Clarifié les responsabilités.

Ces améliorations étaient utiles.

Mais elles ne répondaient jamais complètement à la question fondamentale.

Nous continuions à décrire les systèmes principalement à travers leur structure.

Or la difficulté ne résidait pas dans leur structure.

Elle résidait dans leur évolution.

Peu à peu, une idée simple s'est imposée.

Un système n'est pas seulement constitué de ce qu'il contient.

Il est défini par les transformations qui le font évoluer.

Chaque transformation possède un état d'entrée.

Elle applique des règles explicites.

Elle produit un nouvel état.

Cette succession de transformations constitue la véritable histoire du système.

À partir de ce moment, l'architecture change de nature.

Elle ne consiste plus uniquement à organiser des composants.

Elle consiste à organiser des transformations.

Chaque transformation devient un élément explicite de l'architecture.

Chaque transformation possède une responsabilité clairement identifiée.

Chaque transformation peut être comprise, testée, remplacée et validée indépendamment des autres.

La cohérence globale ne repose plus uniquement sur les objets manipulés.

Elle repose sur la succession des transformations qui relient les différents états de connaissance.

Cette manière de penser présente une conséquence importante.

L'architecture cesse d'être une photographie du système.

Elle devient la description de son évolution.

Les composants conservent naturellement leur importance.

Les objets demeurent indispensables.

Les services, les interfaces et les bases de données restent présents.

Mais ils ne constituent plus le cœur de l'architecture.

Ils deviennent les acteurs d'un processus de transformation plus général.

C'est cette inversion de perspective qui marque la naissance de la State Transformation Architecture.

La question n'est plus :

« Quels composants faut-il construire ? »

Elle devient :

« Quelles transformations faut-il maîtriser ? »

À partir de cette idée, les architectures peuvent être conçues comme des successions de transformations explicites, reproductibles et gouvernables.

Cette approche ne dépend d'aucun langage.

Elle ne dépend d'aucune technologie.

Elle ne dépend d'aucun domaine particulier.

Elle constitue une manière générale de penser les systèmes dont la mission est de faire évoluer une connaissance.

Les chapitres qui suivent vont progressivement formaliser cette intuition.

Ils montreront comment les notions d'état, de transformation, de responsabilité et de gouvernance peuvent constituer les fondements d'une nouvelle architecture des systèmes de connaissance.

Toute architecture repose sur un vocabulaire.

Avant de décrire des composants, des moteurs ou des applications, il est nécessaire d'identifier les concepts les plus simples à partir desquels le reste pourra être construit.

La State Transformation Architecture repose sur trois notions fondamentales :

• les états ;
• les transformations ;
• les règles.

Ces trois concepts sont volontairement généraux.

Ils ne dépendent ni d'un langage de programmation, ni d'un domaine d'application, ni d'une technologie particulière.

Ils décrivent la manière dont une connaissance évolue.

Un état représente la connaissance disponible à un instant donné.

Il ne décrit pas seulement des données.

Il représente tout ce qu'un système considère comme vrai à un moment précis de son évolution.

Selon le contexte, un état peut prendre des formes très différentes.

Il peut s'agir d'un document.

D'un ensemble de transactions blockchain.

D'un modèle de connaissance.

D'une publication.

Ou de toute autre représentation de l'information.

La State Transformation Architecture ne s'intéresse pas à la nature de cet état.

Elle s'intéresse à son évolution.

Une transformation fait évoluer un état vers un autre.

Elle constitue l'unité fondamentale de l'architecture.

Une transformation possède toujours :

• un ou plusieurs états d'entrée ;
• une responsabilité clairement définie ;
• un ensemble de règles ;
• un état produit.

Elle ne cherche pas à résoudre tous les problèmes.

Elle réalise une seule évolution identifiable.

Cette responsabilité unique rend la transformation compréhensible, testable et remplaçable.

L'architecture devient alors une succession explicite de transformations.

Une transformation n'est jamais arbitraire.

Elle applique des règles.

Ces règles déterminent comment un état peut évoluer vers un autre.

Elles expriment la logique du domaine.

Elles garantissent que deux transformations exécutées dans les mêmes conditions produiront le même résultat.

Les règles constituent ainsi la mémoire explicite des décisions prises par le système.

Elles remplacent progressivement les connaissances implicites qui, dans de nombreux projets, ne subsistent plus que dans la mémoire de leurs auteurs.

Ces trois notions ne prennent leur véritable sens que lorsqu'elles sont considérées ensemble.

Les états représentent la connaissance disponible.

Les règles décrivent les conditions de son évolution.

Les transformations appliquent ces règles pour produire une nouvelle connaissance.

L'architecture n'est donc plus une simple organisation de composants.

Elle devient la description explicite d'une succession de transformations gouvernées par des règles.

Chaque état possède une origine.

Chaque transformation possède une responsabilité.

Chaque règle possède une justification.

La connaissance produite par le système cesse alors d'être le résultat d'une accumulation de décisions difficilement explicables.

Elle devient le produit d'une évolution progressive dont chaque étape peut être comprise, reproduite et validée.

Ces trois concepts constituent le vocabulaire fondamental de la State Transformation Architecture.

Les chapitres suivants montreront comment ils permettent de concevoir des systèmes capables de gouverner durablement leur propre évolution.

Toute architecture repose sur des décisions.

Certaines sont prises par les concepteurs.

D'autres sont intégrées dans les règles métier.

D'autres encore résultent des choix effectués par les utilisateurs ou des informations fournies au système.

Dans les architectures classiques, ces décisions sont souvent dispersées.

Certaines sont enfouies dans le code.

D'autres apparaissent dans des fichiers de configuration.

Quelques-unes sont documentées.

Beaucoup ne le sont jamais.

Au fil du temps, leur origine devient difficile à retrouver.

Le système continue de fonctionner.

Mais il devient progressivement plus difficile d'expliquer pourquoi il fonctionne de cette manière.

La State Transformation Architecture adopte un point de vue différent.

Une transformation n'est pas seulement un mécanisme de calcul. Elle est l'expression d'une décision architecturale.

Elle représente une décision architecturale.

Chaque transformation exprime explicitement une intention.

Elle indique pourquoi un état doit évoluer.

Elle applique les règles qui gouvernent cette évolution.

Elle produit un nouvel état dont l'origine demeure explicable. L'architecture cesse ainsi d'être une simple organisation de composants.

Elle devient une organisation de décisions.

Cette différence est fondamentale.

Les composants peuvent évoluer.

Les technologies peuvent être remplacées.

Les langages peuvent changer.

Les décisions constituent la véritable continuité de la connaissance produite par le système.

Préserver ces décisions devient alors un objectif architectural.

Une décision explicite peut être comprise.

Elle peut être discutée.

Elle peut être validée.

Elle peut être remplacée lorsqu'elle ne répond plus aux besoins.

À l'inverse, une décision implicite finit souvent par disparaître avec ceux qui l'ont prise.

La gouvernance consiste précisément à rendre ces décisions visibles.

Chaque transformation porte une responsabilité clairement identifiée.

Chaque règle exprime une décision.

Chaque état résulte d'une succession de décisions explicites.

L'évolution du système ne dépend alors plus uniquement de son implémentation.

Elle dépend de la qualité des décisions qui organisent ses transformations.

Une architecture gouvernable est donc une architecture capable de conserver, d'expliquer et de faire évoluer ses décisions au même titre que ses données ou ses composants.

Cette idée prendra toute son importance lorsque nous étudierons des systèmes dont la mission n'est plus seulement de traiter des données, mais de produire, transformer et gouverner des connaissances.

Toutes les architectures ne poursuivent pas le même objectif.

Certaines traitent des transactions.

D'autres gèrent des utilisateurs.

D'autres encore orchestrent des processus industriels ou des échanges d'informations.

Ces systèmes manipulent principalement des données.

Ils produisent des résultats.

Mais certains domaines présentent une difficulté supplémentaire.

Ils ne cherchent pas uniquement à produire un résultat.

Ils cherchent à comprendre.

L'investigation appartient à cette catégorie.

Son objectif n'est pas seulement de répondre à une question.

Il consiste à expliquer pourquoi une situation est devenue ce qu'elle est.

Une investigation cherche des causes.

Elle établit des relations.

Elle confronte des hypothèses.

Elle valide des observations.

Elle construit progressivement une connaissance.

Cette différence change profondément la nature du système.

Dans un système transactionnel, une opération correcte suffit généralement.

Dans un système d'investigation, un résultat ne possède de valeur que si son origine peut être démontrée.

Chaque conclusion doit pouvoir être justifiée.

Chaque affirmation doit pouvoir être reliée aux éléments qui l'ont produite.

Chaque étape du raisonnement doit rester explicable.

Autrement dit, l'investigation ne consiste pas seulement à accumuler des informations.

Elle consiste à construire une connaissance reproductible.

Cette exigence dépasse largement le domaine de la criminalistique.

Elle apparaît dans la recherche scientifique.

Dans l'analyse de données.

Dans l'audit.

Dans la cybersécurité.

Dans l'étude des blockchains.

Et, plus généralement, dans tous les domaines où il devient nécessaire d'expliquer un résultat plutôt que de simplement le produire.

Nous avons progressivement compris que les architectures classiques répondaient imparfaitement à ce besoin.

Elles permettent de traiter des données avec efficacité.

Elles permettent de construire des applications performantes.

Mais elles rendent rarement explicite la manière dont une connaissance est produite.

Or une investigation est précisément une succession de transformations de connaissance.

Chaque observation modifie la compréhension de la situation.

Chaque hypothèse fait évoluer l'état de la connaissance.

Chaque validation transforme à nouveau cet état.

L'investigation apparaît alors sous un jour nouveau.

Elle n'est plus une suite d'opérations techniques.

Elle devient une succession de transformations gouvernées par des règles explicites.

C'est cette observation qui allait conduire à la conception du premier atelier d'investigation construit selon les principes de la State Transformation Architecture.

La State Transformation Architecture est née d'une réflexion générale sur la gouvernance de la connaissance.

Mais une architecture ne prend véritablement son sens que lorsqu'elle est confrontée à un problème réel.

Ce premier terrain d'application fut l'investigation.

À première vue, une investigation semble consister à rechercher des informations.

En réalité, son objectif est tout autre.

Une investigation cherche à produire une connaissance suffisamment solide pour pouvoir être expliquée, vérifiée et reproduite.

Cette exigence dépasse largement la simple collecte de données.

Les observations doivent être interprétées.

Les hypothèses doivent être confrontées aux faits.

Les incohérences doivent être identifiées.

Les conclusions doivent pouvoir être justifiées.

Autrement dit, une investigation ne produit pas directement des réponses.

Elle fait progressivement évoluer un état de connaissance.

Chaque observation enrichit ce qui est déjà connu.

Chaque validation renforce ou affaiblit une hypothèse.

Chaque découverte modifie la compréhension globale de la situation.

Cette progression est précisément une succession de transformations.

L'investigation apparaissait alors comme un domaine particulièrement adapté à la State Transformation Architecture.

Les états représentaient les connaissances disponibles.

Les transformations traduisaient les raisonnements, les validations et les enrichissements successifs.

Les règles exprimaient les méthodes d'analyse et les critères permettant de produire une connaissance fiable.

Cette observation allait conduire à une idée nouvelle.

Plutôt que de construire un simple logiciel d'analyse, pourquoi ne pas concevoir un véritable atelier d'investigation ?

Un atelier ne se limite pas à exécuter des traitements.

Il accompagne un travail intellectuel.

Il permet d'observer.

D'expérimenter.

De vérifier.

De documenter.

De revenir sur une hypothèse.

Puis de poursuivre l'investigation à partir d'un nouvel état de connaissance.

Cette distinction est essentielle.

L'objectif n'est plus seulement de calculer.

Il devient de produire une connaissance gouvernable.

C'est ainsi qu'est née l'idée du Forensic Workshop.

À ce stade, il ne s'agissait encore ni d'une implémentation particulière, ni d'un produit.

Seulement d'une première démonstration que la State Transformation Architecture pouvait servir de fondement à un système dont la mission principale consistait à produire de la connaissance plutôt qu'à simplement traiter des données.

Cette première application allait, quelques mois plus tard, ouvrir naturellement la voie à une autre famille de systèmes : les compilateurs de connaissance, dont Governance Publishing constituera la première réalisation.

Toutes les connaissances ne possèdent pas la même valeur.

Certaines permettent simplement de répondre à une question.

D'autres permettent de comprendre.

La différence ne réside pas uniquement dans la qualité des réponses obtenues.

Elle réside dans la manière dont ces réponses ont été produites.

Une connaissance ne devient véritablement utile que lorsqu'elle peut être expliquée.

Elle doit pouvoir être vérifiée.

Elle doit pouvoir être discutée.

Elle doit pouvoir être reproduite.

Autrement dit, sa valeur dépend autant de son origine que de son contenu.

Cette exigence apparaît dans de nombreux domaines.

La recherche scientifique demande que les expériences puissent être reproduites.

L'investigation exige que chaque conclusion puisse être justifiée.

L'audit impose de démontrer le cheminement ayant conduit à une décision.

La publication de connaissances nécessite de préserver la cohérence du raisonnement présenté au lecteur.

Dans tous ces cas, le résultat final ne suffit pas.

Le processus qui l'a produit fait partie intégrante de la connaissance.

Cette observation conduit à une conséquence importante.

La mission d'un système de connaissance ne consiste pas uniquement à produire des informations nouvelles.

Elle consiste à produire une connaissance dont l'évolution reste compréhensible.

Chaque transformation doit pouvoir être expliquée.

Chaque décision doit rester explicite.

Chaque nouvel état doit pouvoir être relié aux états qui l'ont précédé.

La reproductibilité devient alors une propriété architecturale.

Elle ne dépend plus uniquement des algorithmes.

Elle résulte de l'organisation même des transformations qui construisent progressivement la connaissance.

Une architecture gouvernable ne cherche donc pas seulement à produire des résultats exacts.

Elle cherche à produire des résultats dont l'origine demeure intelligible.

Cette distinction est essentielle.

Deux systèmes peuvent parvenir exactement à la même conclusion.

Pourtant, seul celui qui est capable d'expliquer le cheminement ayant conduit à cette conclusion produit une connaissance véritablement gouvernable.

La State Transformation Architecture repose précisément sur cette idée.

Elle considère qu'une connaissance ne peut être durable que si les transformations qui l'ont produite demeurent elles-mêmes explicites, reproductibles et vérifiables.

Cette exigence constitue le fondement des systèmes de connaissance présentés dans la seconde partie de cet ouvrage.

Qu'il s'agisse d'un atelier d'investigation, d'un compilateur de connaissance ou de tout autre système de transformation de la connaissance, leur mission demeure la même.

Ils ne produisent pas simplement des résultats.

Ils produisent une connaissance dont la construction reste visible, explicable et reproductible.

Toute connaissance n'est pas directement exploitable.

Avant de pouvoir être transformée, partagée ou publiée, elle doit pouvoir être identifiée.

C'est le rôle des objets de connaissance.

Un objet de connaissance représente une unité cohérente de connaissance dont le système peut assurer la production, la transformation, la validation ou la conservation.

Il ne s'agit pas nécessairement d'un objet informatique.

Il s'agit avant tout d'une unité de sens.

Selon le domaine, cette unité peut prendre des formes très différentes.

Dans un atelier d'investigation, un objet de connaissance pourra représenter une hypothèse, une observation, une preuve, un événement ou une conclusion.

Dans un compilateur de connaissance, il pourra représenter un document, un fragment, une expérience de lecture ou une publication.

La State Transformation Architecture ne définit pas la nature de ces objets.

Elle fournit le cadre dans lequel ils évoluent.

Chaque objet possède un état.

Chaque objet peut être transformé.

Chaque objet participe à la construction progressive d'une connaissance plus riche.

Cette idée possède une conséquence importante.

Les systèmes ne manipulent plus uniquement des données.

Ils manipulent des objets porteurs de connaissance.

Une donnée isolée possède rarement une signification complète.

Elle prend son sens lorsqu'elle est intégrée dans un objet de connaissance et replacée dans le contexte des transformations qui l'ont produite.

Ainsi, deux systèmes manipulant exactement les mêmes données pourront produire des connaissances très différentes selon les objets qu'ils construisent et les transformations qu'ils appliquent.

Les objets de connaissance constituent ainsi le lien entre les transformations et les usages.

Ils sont suffisamment stables pour être compris.

Suffisamment riches pour être transformés.

Suffisamment explicites pour être gouvernés.

À partir de ce moment, l'architecture ne consiste plus uniquement à faire évoluer des états.

Elle consiste à faire évoluer des objets de connaissance dont chaque transformation demeure compréhensible.

Cette idée ouvre naturellement la voie à une nouvelle famille de systèmes.

Certains auront pour mission de produire ces objets de connaissance.

D'autres auront pour mission de les organiser.

D'autres encore les transformeront en expériences adaptées à leurs utilisateurs.

Les objets de connaissance ne sont pas destinés à être consommés directement. Ils constituent la matière première à partir de laquelle différentes expériences peuvent être construites selon les besoins des utilisateurs.

La seconde partie de cet ouvrage présentera l'une de ces spécialisations : un compilateur de connaissance destiné à construire une expérience de lecture, puis à la transformer en publication.

L'apparition des modèles d'intelligence artificielle soulève naturellement une question.

Une State Transformation Architecture repose sur une succession de transformations explicites, déterministes et observables.

Comment une intelligence artificielle peut-elle trouver sa place dans une telle architecture ?

La réponse tient à la distinction entre production et exploration de la connaissance.

Les transformations d'une State Transformation Architecture produisent des états de connaissance.

Ces transformations sont explicites, reproductibles et vérifiables.

À partir d'un même état initial, elles conduisent toujours au même résultat.

L'intelligence artificielle ne possède pas ces propriétés.

Ses réponses peuvent évoluer avec le modèle utilisé, son entraînement ou son contexte d'exécution.

Pour cette raison, une intelligence artificielle ne doit pas constituer une transformation de production de la connaissance.

En revanche, elle peut jouer un rôle essentiel dans son exploration.

À partir d'un état de connaissance construit de manière déterministe, une intelligence artificielle peut proposer des rapprochements, mettre en évidence des régularités, suggérer des hypothèses ou attirer l'attention sur des situations particulières.

Ces propositions ne constituent pas une nouvelle connaissance.

Elles demeurent des hypothèses.

Une hypothèse ne devient une connaissance qu'après une nouvelle transformation explicite de validation.

Cette validation peut être réalisée par un expert humain, par un processus métier ou par tout autre mécanisme répondant aux exigences de la State Transformation Architecture.

Ainsi, l'intelligence artificielle n'est pas exclue de la STA.

Elle y occupe une place précise.

La connaissance est construite par des transformations déterministes.

L'intelligence artificielle explore cette connaissance.

La validation transforme éventuellement ces hypothèses en un nouvel état de connaissance.

Cette distinction préserve les propriétés fondamentales de la State Transformation Architecture tout en permettant de bénéficier de la puissance des modèles d'intelligence artificielle dans les activités d'analyse, d'investigation et d'aide à la décision.

Les chapitres précédents ont montré qu'un système de connaissance ne manipule pas uniquement des données.

Il produit progressivement des objets de connaissance dont chaque transformation demeure explicable et reproductible.

Une nouvelle question apparaît alors.

Comment ces objets deviennent-ils accessibles à leurs utilisateurs ?

La réponse pourrait sembler évidente.

Il suffirait de les afficher.

Pourtant, cette solution se révèle rapidement insuffisante.

Les objets de connaissance sont conçus pour préserver la richesse de la connaissance produite.

Ils contiennent les informations nécessaires à leur évolution, leur validation et leur gouvernance.

Ils ne sont pas nécessairement adaptés à une consultation directe.

Selon les utilisateurs, les besoins diffèrent profondément.

Un chercheur souhaitera conserver toutes les étapes d'un raisonnement.

Un enquêteur privilégiera les éléments utiles à une investigation.

Un décideur recherchera une synthèse.

Un lecteur attendra une progression cohérente lui permettant de comprendre progressivement un sujet.

À partir des mêmes objets de connaissance, plusieurs expériences deviennent donc possibles.

Aucune ne constitue une simple opération d'affichage.

Toutes nécessitent une succession de transformations.

Certaines sélectionneront les objets pertinents.

D'autres les organiseront.

D'autres encore construiront une progression adaptée au contexte de consultation.

Chaque expérience possède ainsi sa propre logique de transformation.

Cette observation conduit naturellement à une nouvelle catégorie de systèmes.

Leur rôle n'est plus de produire des objets de connaissance.

Leur rôle consiste à construire une expérience à partir de ces objets.

Ils réalisent une succession de transformations gouvernées, reproductibles et explicables, conduisant progressivement à un artefact destiné à un usage particulier.

C'est précisément ce que nous appellerons un compilateur de connaissance.

À l'image d'un compilateur logiciel, il ne crée pas l'information qu'il manipule.

Il transforme progressivement une représentation vers une autre, en appliquant des règles explicites et vérifiables.

La différence est que les transformations portent ici sur des objets de connaissance plutôt que sur du code.

Chaque étape conserve la cohérence de la connaissance tout en la rapprochant de l'expérience recherchée.

Un compilateur de connaissance n'est donc pas un moteur de rendu.

Il ne se limite pas à produire un document final.

Il gouverne l'ensemble des transformations qui relient les objets de connaissance à une expérience destinée à leurs utilisateurs.

La publication d'un livre constitue l'une des applications possibles de cette architecture.

Les chapitres qui suivent présenteront la première réalisation construite selon ces principes : Governance Publishing.

Les principes présentés jusqu'ici ne décrivent pas un domaine particulier.

Ils proposent une manière d'organiser la production et la transformation de la connaissance.

Encore faut-il montrer qu'une telle architecture peut être mise en œuvre.

Governance Publishing constitue la première réalisation conçue entièrement selon ces principes.

Son objectif n'est pas de produire un document.

Son objectif est de transformer progressivement des objets de connaissance en une expérience de lecture cohérente, avant de les matérialiser sous la forme d'une publication.

Cette distinction est essentielle.

Une publication n'est pas le résultat d'un simple export.

Elle est l'aboutissement d'une succession de transformations.

Chaque transformation poursuit un objectif précis.

Certaines organisent les objets de connaissance.

D'autres construisent une progression adaptée au lecteur.

D'autres encore préparent la composition des futures pages.

Enfin, les dernières transformations matérialisent cette expérience sous une forme publiable.

Aucune de ces étapes n'est arbitraire.

Chacune applique des règles explicites.

Chacune produit un nouvel état.

Chacune demeure reproductible.

L'ensemble constitue un véritable processus de compilation.

Comme tout compilateur, Governance Publishing ne crée pas son contenu.

Il transforme progressivement une représentation de la connaissance vers une autre.

Chaque représentation est spécialisée pour répondre à une intention particulière.

La richesse de l'architecture réside précisément dans cette succession d'états intermédiaires.

Aucun d'eux n'est un simple détail d'implémentation.

Tous représentent des objets de travail possédant leur propre cohérence et leur propre responsabilité.

Cette approche offre plusieurs avantages.

Elle rend chaque transformation indépendante.

Elle facilite la validation de chaque étape.

Elle permet de faire évoluer une partie de la chaîne sans remettre en cause l'ensemble.

Elle autorise également la création de nouvelles chaînes de compilation partageant les mêmes objets de connaissance tout en poursuivant des objectifs différents.

Ainsi, Governance Publishing ne constitue pas une exception.

Il représente la première spécialisation d'une famille plus vaste de compilateurs de connaissance.

Les chapitres qui suivent décrivent les différentes transformations qui composent cette première architecture de compilation.

Les objets de connaissance constituent la matière première d'un compilateur de connaissance.

Ils décrivent ce qui est connu.

Ils ne décrivent pas encore la manière dont cette connaissance sera découverte par un utilisateur.

Or une connaissance n'est jamais reçue dans sa totalité.

Elle est toujours vécue progressivement.

Chaque lecteur découvre un sujet selon une succession d'étapes.

Certaines notions doivent être introduites avant d'autres.

Certaines relations doivent être rendues explicites.

Certaines explications doivent être différées afin de préserver la cohérence de l'ensemble.

Cette progression fait partie intégrante de l'expérience.

Elle ne peut être réduite à une simple opération de mise en page.

C'est précisément le rôle de la Knowledge Experience.

Une Knowledge Experience constitue la première représentation orientée vers l'utilisateur construite à partir d'objets de connaissance.

Elle ne modifie pas la connaissance elle-même.

Elle organise la manière dont cette connaissance pourra être découverte.

Cette distinction est essentielle.

Les objets de connaissance demeurent indépendants de leurs usages.

Une même connaissance pourra ainsi donner naissance à plusieurs expériences différentes.

Une publication pédagogique.

Un rapport d'investigation.

Une documentation technique.

Une présentation interactive.

Ou toute autre forme adaptée à un contexte particulier.

La Knowledge Experience représente donc un choix d'intention.

Elle exprime ce que l'utilisateur devra comprendre.

Les concepts qui devront être rapprochés.

Le rythme selon lequel ils seront découverts.

Les liens qui devront rester visibles tout au long de cette progression.

À ce stade, aucune page n'existe encore.

Aucun chapitre.

Aucun fragment.

Aucune mise en forme.

L'expérience décrit uniquement la manière dont la connaissance devra être parcourue.

Elle constitue ainsi le premier état spécialisé d'un compilateur de connaissance.

Les transformations qui suivront n'auront plus pour mission de définir l'intention de lecture.

Elles auront pour rôle de matérialiser progressivement cette intention sous une forme publiable.

La Knowledge Experience marque ainsi la transition entre la connaissance produite et les différentes expériences susceptibles d'en être construites.

Elle constitue le point de départ de toute chaîne de compilation orientée vers un utilisateur.

Une Knowledge Experience décrit la manière dont une connaissance doit être découverte.

Elle exprime une intention.

Cette intention doit maintenant être transformée en une structure de publication.

C'est le rôle de la Publication Composition.

La Publication Composition ne produit pas encore une publication.

Elle construit l'organisation intellectuelle de celle-ci.

Elle détermine les grandes parties.

Les chapitres.

Les sections.

Les relations qui devront être conservées entre les différents ensembles de connaissances.

À ce stade, la préoccupation n'est toujours pas la mise en page.

Elle concerne exclusivement la structure.

Une même Knowledge Experience pourra conduire à plusieurs compositions différentes.

Selon les objectifs poursuivis, certaines connaissances pourront être rapprochées.

D'autres séparées.

Certaines mises en avant.

D'autres laissées en arrière-plan.

La Publication Composition représente donc un premier travail d'organisation.

Elle construit une architecture éditoriale cohérente sans encore s'intéresser à la manière dont celle-ci sera matérialisée.

Cette séparation possède une conséquence importante.

L'organisation intellectuelle d'une publication devient indépendante de sa réalisation matérielle.

Une même composition pourra ainsi être publiée sous des formes très différentes.

Livre imprimé.

Site Web.

Documentation interactive.

Support de formation.

Ou toute autre forme adaptée à son contexte de diffusion.

La Publication Composition constitue ainsi un nouvel état intermédiaire du compilateur.

Elle reçoit une intention de lecture.

Elle produit une structure éditoriale.

Les transformations suivantes s'appuieront sur cette structure pour construire progressivement une expérience de lecture de plus en plus concrète.

Cette étape illustre l'un des principes fondamentaux de la State Transformation Architecture.

Chaque transformation poursuit une responsabilité unique.

La Knowledge Experience définit l'intention.

La Publication Composition construit l'organisation.

Les transformations suivantes prépareront ensuite les éléments nécessaires à la matérialisation de cette organisation.

La Publication Composition construit l'organisation intellectuelle d'une publication.

Elle définit les grandes parties de l'œuvre, leurs relations et leur rôle dans la progression de la lecture.

Cette organisation reste cependant abstraite.

Avant de pouvoir planifier la lecture ou préparer la composition des pages, le compilateur doit identifier les unités éditoriales qui composeront effectivement la publication.

C'est le rôle de la Fragment Composition.

Un fragment est une unité éditoriale cohérente.

Il possède une intention propre.

Il réunit les éléments nécessaires à cette intention tout en restant indépendant des choix de présentation.

Selon la nature de la publication, les fragments pourront prendre des formes très différentes.

Dans un ouvrage, ils pourront correspondre à une couverture, une préface, une table des matières, un chapitre, une annexe ou un index.

Dans un rapport d'investigation, ils pourront représenter un résumé exécutif, une chronologie, une présentation des constatations (Findings), des éléments de preuve (Evidence) ou des recommandations.

La nature exacte des fragments dépend du domaine.

Leur rôle architectural demeure identique.

Ils constituent les unités éditoriales à partir desquelles sera construite l'expérience de lecture.

La Fragment Composition ne produit donc ni des pages, ni une mise en forme.

Elle construit un ensemble de fragments possédant chacun une responsabilité éditoriale clairement identifiée.

Ces fragments pourront ensuite être ordonnés, enrichis et adaptés au support de publication sans remettre en cause leur cohérence.

Cette étape illustre une nouvelle fois l'un des principes de la State Transformation Architecture.

Chaque transformation crée un nouvel état spécialisé.

La Publication Composition organise la connaissance.

La Fragment Composition identifie les unités éditoriales qui permettront de la communiquer.

Les transformations suivantes construiront progressivement une expérience de lecture complète à partir de ces fragments.

Les fragments constituent les unités éditoriales d'une publication.

Ils ne définissent pas encore la manière dont le lecteur les découvrira.

Deux publications peuvent contenir exactement les mêmes fragments tout en produisant des expériences de lecture profondément différentes.

La différence réside dans le parcours proposé au lecteur.

C'est le rôle du Reading Plan.

Le Reading Plan décrit la progression de la lecture.

Il organise la découverte progressive de la connaissance.

Il définit l'ordre dans lequel les fragments seront rencontrés.

Mais son rôle ne se limite pas à une simple succession.

Il peut prévoir qu'une notion soit introduite avant d'être pleinement expliquée.

Qu'une idée soit rappelée plus loin dans la lecture.

Qu'un fragment prépare la compréhension d'un autre.

Ou qu'une révélation soit volontairement différée afin de préserver la progression du raisonnement.

Ainsi, le Reading Plan ne décrit pas uniquement un ordre.

Il décrit une expérience de découverte.

Cette distinction est essentielle.

Une même Publication Composition pourra donner naissance à plusieurs plans de lecture.

Selon les objectifs poursuivis, certains fragments pourront être déplacés.

D'autres regroupés.

Certains parcours pourront privilégier une découverte progressive.

D'autres une consultation rapide.

D'autres encore une navigation non linéaire.

La structure éditoriale demeure inchangée.

Le parcours proposé au lecteur évolue.

Le Reading Plan constitue ainsi un nouvel état spécialisé du compilateur.

Il reçoit un ensemble de fragments.

Il construit un parcours de lecture cohérent adapté à une intention donnée.

Les transformations suivantes n'auront plus pour mission d'organiser la progression intellectuelle de la publication.

Elles prépareront sa matérialisation dans un support concret.

Cette étape confirme une nouvelle fois le principe fondamental du compilateur de connaissance.

Chaque transformation répond à une question différente.

La Knowledge Experience définit l'intention.

La Publication Composition construit l'organisation.

La Fragment Composition identifie les unités éditoriales.

Le Reading Plan construit l'expérience de découverte.

En séparant ces responsabilités, le compilateur conserve la possibilité de faire évoluer chacune d'elles indépendamment, tout en préservant la cohérence de l'ensemble.

Le Reading Plan décrit le parcours proposé au lecteur.

Il représente le résultat d'une succession de décisions éditoriales.

Ces décisions ne sont cependant pas arbitraires.

Elles répondent à des principes de lecture explicitement définis.

C'est le rôle des Reading Policies.

Une Reading Policy ne décrit pas une publication.

Elle ne décrit pas davantage un parcours de lecture.

Elle exprime les règles qui gouvernent la construction de ce parcours.

Ces règles peuvent poursuivre des objectifs très différents.

Favoriser une découverte progressive.

Préserver le suspense.

Introduire les concepts les plus simples avant les plus complexes.

Rapprocher des notions complémentaires.

Limiter la charge cognitive.

Ou, au contraire, privilégier une consultation rapide par un utilisateur déjà expérimenté.

Une même Knowledge Experience pourra ainsi conduire à plusieurs Reading Plans selon les politiques retenues.

La connaissance demeure identique.

L'expérience de lecture évolue.

Cette distinction est fondamentale.

Le compilateur ne fige pas une manière unique de présenter la connaissance.

Il sépare la connaissance produite, les parcours possibles et les règles qui permettent de construire ces parcours.

Les Reading Policies deviennent ainsi des objets de gouvernance.

Elles rendent explicites les décisions éditoriales qui seraient autrement implicites.

Elles peuvent être discutées.

Comparées.

Testées.

Améliorées.

Ou remplacées sans remettre en cause les objets de connaissance eux-mêmes.

Cette séparation constitue l'un des principes fondamentaux d'un compilateur de connaissance.

Les états décrivent ce qui est produit.

Les politiques gouvernent la manière dont ces états sont construits.

Ainsi, le compilateur ne produit pas uniquement une publication.

Il produit une publication dont les choix éditoriaux demeurent explicables et reproductibles.

Les transformations qui suivront appliqueront ces choix pour construire progressivement la matérialisation de l'expérience de lecture.

Les transformations précédentes ont progressivement construit une expérience de lecture.

Cette expérience possède désormais une intention, une organisation, des fragments, un parcours et des politiques qui gouvernent sa progression.

Elle n'est cependant encore liée à aucun support.

Le lecteur ne découvre pas une publication de manière abstraite.

Il la découvre dans un espace.

Une page imprimée.

Un écran.

Une tablette.

Ou tout autre environnement de lecture.

La Page Composition constitue la transformation qui organise l'expérience de lecture dans cet espace.

Son rôle n'est pas de produire un rendu final.

Il consiste à déterminer comment les différents éléments de l'expérience prendront place dans le support choisi.

Cette étape répond à des questions nouvelles.

Quels fragments doivent apparaître ensemble ?

Où débute une nouvelle page ?

Quels éléments doivent rester visibles simultanément ?

Comment préserver la continuité de la lecture lorsque l'espace disponible devient insuffisant ?

Ces décisions ne relèvent pas encore du moteur de rendu.

Elles appartiennent à la composition.

Une même expérience de lecture pourra ainsi conduire à plusieurs compositions de pages.

Un ouvrage imprimé.

Une publication numérique.

Une documentation consultée sur téléphone.

Ou un écran de grande dimension.

L'expérience demeure identique.

L'organisation spatiale évolue selon les contraintes du support.

La Page Composition constitue ainsi un nouvel état spécialisé du compilateur.

Elle reçoit une expérience de lecture structurée.

Elle produit une organisation spatiale indépendante des technologies de rendu.

Cette séparation possède un avantage majeur.

Les choix éditoriaux demeurent indépendants des choix techniques.

La composition des pages établit l'organisation spatiale de l'expérience de lecture. Cette organisation constitue désormais le support sur lequel pourra être définie l'expérience finale proposée au lecteur.

Les transformations précédentes ont progressivement construit une publication.

La connaissance a été organisée.

Les fragments ont été identifiés.

Le parcours de lecture a été défini.

Les politiques éditoriales ont été appliquées.

La composition des pages a été établie.

Il reste désormais à considérer l'ensemble de ces décisions du point de vue du lecteur.

C'est le rôle de la Reading Experience.

La Reading Experience ne décrit plus la manière dont la publication est construite.

Elle décrit la manière dont elle sera vécue.

Elle représente l'expérience complète proposée au lecteur, indépendamment de la technologie qui permettra de la matérialiser.

Cette distinction est essentielle.

Deux publications pourront partager exactement la même expérience de lecture tout en étant diffusées sur des supports très différents.

Inversement, deux publications produites à partir des mêmes objets de connaissance pourront offrir des expériences de lecture très différentes.

La Reading Experience constitue ainsi la synthèse de toutes les transformations précédentes.

Elle ne remplace aucune d'entre elles.

Elle les rassemble dans une représentation unique, entièrement orientée vers l'utilisateur.

À ce stade, le compilateur ne s'intéresse plus aux objets de connaissance.

Il ne s'intéresse plus aux structures éditoriales.

Il ne s'intéresse plus aux fragments ni aux pages.

Il considère uniquement l'expérience qui sera proposée au lecteur.

Cette représentation devient alors indépendante des moteurs de rendu.

Elle pourra être matérialisée sous différentes formes sans que l'expérience elle-même soit remise en cause.

Ainsi, une même Reading Experience pourra donner naissance à un livre imprimé, une publication numérique, une documentation interactive ou tout autre support adapté à son contexte d'utilisation.

La Reading Experience constitue le dernier état conceptuel du compilateur.

À ce stade, l'expérience de lecture est entièrement définie. Les transformations qui suivent n'auront plus pour mission de la modifier, mais uniquement de la matérialiser fidèlement dans différents artefacts de publication.

Une State Transformation Architecture distingue deux familles de transformations.

Les transformations constructives produisent progressivement un nouvel état de connaissance. Chaque transformation enrichit, organise ou valide cet état.

Les transformations de matérialisation ne produisent plus de connaissance nouvelle. Leur rôle consiste à représenter fidèlement un état de connaissance déjà achevé dans un ou plusieurs artefacts destinés à leurs utilisateurs.

Cette séparation garantit que la connaissance demeure indépendante de ses représentations.

La Reading Experience décrit intégralement l'expérience destinée au lecteur.

Elle demeure cependant indépendante de toute technologie de diffusion.

Avant qu'un moteur puisse produire une publication, cette expérience doit être traduite dans une représentation abstraite destinée à être matérialisée.

C'est le rôle du Rendering.

Le Rendering ne produit pas encore un document.

Il construit une représentation abstraite qui pourra ensuite être interprétée par un moteur de rendu.

Cette représentation conserve l'ensemble des décisions prises lors des transformations précédentes : l'intention de lecture, l'organisation éditoriale, les fragments, le parcours de découverte, les politiques éditoriales, la composition des pages et, plus généralement, la totalité de la Reading Experience.

Aucune de ces informations n'est perdue.

Elles sont simplement traduites dans une représentation destinée à leur future matérialisation.

Cette distinction est essentielle.

Le Rendering ne dépend ni du HTML, ni du PDF, ni d'un format particulier.

Il construit une représentation abstraite que différents moteurs pourront ensuite interpréter.

Cette séparation présente plusieurs avantages.

Une même expérience de lecture pourra être matérialisée sous plusieurs formes sans modifier les transformations qui l'ont produite.

Inversement, un nouveau moteur de rendu pourra être ajouté sans remettre en cause le compilateur.

Le Rendering constitue ainsi la frontière entre les transformations constructives de la connaissance et les transformations de matérialisation.

Il marque le moment où l'architecture quitte le domaine de la construction de la connaissance pour entrer dans celui de sa matérialisation.

Les transformations qui suivent n'auront plus pour mission de transformer la connaissance.

Elles auront pour seule responsabilité de la matérialiser fidèlement dans les différents artefacts de publication.

Le Rendering produit une représentation destinée à être matérialisée.

Cette représentation demeure indépendante des technologies de publication.

Sa transformation en un artefact concret est confiée à un Rendering Engine.

Le Rendering Engine ne participe pas à la construction de la connaissance.

Il ne décide ni de l'organisation de la publication, ni du parcours de lecture, ni de la composition des pages.

Toutes ces décisions ont déjà été prises par le compilateur de connaissance.

Le moteur de rendu reçoit une représentation entièrement définie.

Sa responsabilité consiste uniquement à la matérialiser fidèlement dans un format donné.

Selon les besoins, plusieurs moteurs pourront coexister.

Un moteur HTML.

Un moteur PDF.

Un moteur EPUB.

Ou tout autre moteur adapté à un contexte particulier.

Tous partageront la même représentation produite par le compilateur.

Cette séparation présente plusieurs avantages.

L'évolution d'un moteur de rendu n'a aucun impact sur la chaîne de compilation.

Inversement, une évolution du compilateur ne remet pas en cause les moteurs existants tant que le contrat de Rendering demeure stable.

Le Rendering Engine constitue ainsi une spécialisation technique.

Il traduit une représentation abstraite vers une technologie particulière.

Il ne modifie jamais l'intention éditoriale.

Il ne crée aucune connaissance.

Il ne transforme pas l'expérience de lecture.

Il la matérialise.

Cette distinction est essentielle.

Les choix éditoriaux appartiennent au compilateur.

Les choix techniques appartiennent au moteur de rendu.

En séparant explicitement ces responsabilités, l'architecture conserve son indépendance vis-à-vis des technologies de publication.

Elle peut évoluer vers de nouveaux supports sans remettre en cause les transformations qui ont construit la connaissance.

Le Rendering Engine constitue ainsi le dernier maillon de la chaîne de transformation.

Son rôle n'est pas de produire une nouvelle représentation.

Il consiste à donner une existence concrète à celle qui a déjà été construite.

Le Rendering Engine matérialise la représentation produite par le compilateur.

Le résultat de cette transformation est un artefact de publication.

Un artefact est une matérialisation concrète d'une expérience construite à partir d'objets de connaissance.

Selon les besoins, cet artefact pourra prendre des formes très différentes.

Un livre imprimé.

Un document PDF.

Un site Web.

Une documentation interactive.

Un livre numérique.

Ou tout autre support de diffusion.

Ces différences n'affectent pas la connaissance produite.

Elles n'affectent pas davantage les transformations qui ont conduit à cette publication.

Elles concernent uniquement la forme sous laquelle cette connaissance est rendue accessible à ses utilisateurs.

Cette distinction possède une conséquence importante.

L'artefact ne constitue pas le cœur du système.

Il en est l'aboutissement visible.

La véritable valeur de l'architecture réside dans les transformations successives qui permettent de produire cet artefact de manière gouvernée, reproductible et explicable.

Ainsi, plusieurs artefacts pourront être produits à partir d'une même expérience de lecture.

Inversement, un même type d'artefact pourra être obtenu à partir de compilateurs différents poursuivant des objectifs distincts.

Le livre ne constitue donc pas l'objectif d'un compilateur de connaissance.

Il représente l'une des formes possibles sous lesquelles une connaissance peut être partagée.

Cette idée dépasse largement le domaine de l'édition.

Toute architecture fondée sur la State Transformation Architecture peut produire des artefacts adaptés à son propre contexte.

Un rapport d'investigation.

Une documentation technique.

Une base de connaissances.

Un tableau de bord.

Une interface conversationnelle.

Ou toute autre forme permettant à des utilisateurs d'interagir avec la connaissance produite.

Les artefacts évoluent.

Les technologies changent.

Les usages se transforment.

Les objets de connaissance et les transformations qui les relient demeurent.

C'est cette stabilité qui constitue la véritable force d'un compilateur de connaissance.

Governance Publishing en fournit une première démonstration.

Il montre qu'il est possible de transformer progressivement une connaissance en publication tout en préservant la cohérence, la traçabilité et la gouvernance de chacune des transformations.

Cette première réalisation ne constitue cependant pas une fin.

Elle ouvre la voie à une famille plus vaste de compilateurs de connaissance, capables de construire des expériences et des artefacts adaptés à des domaines très différents.

C'est cette généralisation que la troisième partie de cet ouvrage propose maintenant d'explorer.

Le parcours présenté dans cette deuxième partie pourrait laisser penser que la publication constitue l'aboutissement naturel de toute connaissance.

Il n'en est rien.

La publication n'est qu'une spécialisation parmi d'autres.

Ce que nous avons construit n'est pas une architecture de publication.

C'est une architecture capable de transformer une connaissance en une expérience adaptée à un objectif particulier.

Le livre n'est que l'une des formes que cette expérience peut prendre.

Depuis les premiers objets de connaissance jusqu'au Publication Artifact, chaque étape possède une responsabilité propre.

Chaque transformation produit un nouvel état.

Aucune ne mélange plusieurs responsabilités.

La chaîne de transformation ne décrit donc pas un logiciel particulier.

Elle formalise une manière de faire évoluer une connaissance sans jamais perdre sa cohérence.

Cette succession d'états constitue l'essence même de la State Transformation Architecture.

L'artefact publié ne représente que la dernière étape visible.

L'essentiel se joue bien avant.

Une connaissance devient progressivement une expérience.

Cette expérience est ensuite matérialisée sous une forme adaptée à son destinataire.

Dans Governance Publishing, cette matérialisation produit un livre.

Dans une autre architecture, elle pourrait produire un tableau de bord, un rapport d'investigation, une application interactive, une visualisation ou toute autre forme d'expression.

L'architecture demeure identique.

Seul l'artefact change.

Governance Publishing est le premier compilateur construit à partir de ces principes.

Son domaine est celui de la publication.

Il démontre qu'il est possible de transformer une connaissance en une expérience de lecture au moyen d'une succession explicite de transformations gouvernées.

Mais cette réalisation ne constitue pas l'objectif final.

Elle sert avant tout de démonstrateur d'une architecture plus générale.

Dès lors qu'une connaissance peut être transformée en expérience, rien n'impose que cette expérience soit toujours destinée à être publiée.

Chaque domaine peut définir ses propres objets, ses propres expériences et ses propres artefacts.

La publication devient alors un cas particulier d'un principe beaucoup plus vaste : celui des compilateurs de connaissance.

La partie qui suit quitte donc le domaine de la publication pour montrer comment cette même architecture peut être adaptée à d'autres langages métier, à commencer par le Forensic Workshop.

La State Transformation Architecture ne décrit pas un domaine d'activité.

Elle ne définit ni les objets manipulés, ni les règles propres à un métier particulier.

Son rôle est différent.

Elle fournit un cadre dans lequel un domaine peut organiser la production, la transformation et la gouvernance de sa connaissance.

Chaque domaine possède son propre vocabulaire.

Une investigation manipule des observations, des preuves, des hypothèses et des conclusions.

Un système éditorial manipule des objets de connaissance, des expériences de lecture, des fragments et des publications.

Un domaine médical raisonnera en diagnostics, traitements, examens et recommandations.

Un système industriel utilisera d'autres concepts encore.

Ces différences ne remettent pas en cause l'architecture.

Elles constituent simplement des spécialisations d'un même principe général.

La State Transformation Architecture fournit un langage architectural.

Chaque métier construit ensuite son propre langage métier à l'intérieur de ce cadre.

Cette distinction est essentielle.

Les concepts métier évoluent naturellement avec les connaissances et les pratiques de chaque domaine.

L'architecture, elle, demeure stable.

Elle continue à organiser les états, les transformations, les règles, les politiques et les artefacts qui structurent l'évolution de la connaissance.

Ainsi, deux systèmes appartenant à des domaines très différents pourront partager exactement la même architecture tout en manipulant des objets complètement différents.

Ce qu'ils auront en commun ne sera pas leur vocabulaire.

Ce sera la manière dont ce vocabulaire évolue.

Cette approche offre un avantage majeur.

Chaque langage métier peut évoluer indépendamment de l'architecture qui le porte.

De nouveaux objets peuvent apparaître.

D'anciennes notions peuvent disparaître.

Les règles métier peuvent être enrichies.

Les politiques peuvent être adaptées.

Sans remettre en cause les principes de transformation qui assurent la cohérence du système.

La State Transformation Architecture ne cherche donc pas à unifier les métiers.

Elle cherche à leur offrir une manière commune d'organiser leurs transformations.

Elle ne remplace pas les langages métier.

Elle leur fournit un cadre dans lequel ils peuvent évoluer de manière gouvernable, reproductible et explicable.

Cette distinction ouvre naturellement la voie à des spécialisations très différentes.

Le chapitre suivant présentera l'une d'elles : le Forensic Workshop, conçu comme un langage métier dédié à la production de connaissances d'investigation.

La State Transformation Architecture n'a pas vocation à rester une théorie.

Elle trouve tout son sens lorsqu'elle est spécialisée pour répondre aux besoins d'un domaine particulier.

Le Forensic Workshop constitue l'une de ces spécialisations.

Sa mission n'est pas d'explorer une blockchain.

Elle n'est pas davantage de produire des visualisations ou des rapports.

Sa mission est de produire une connaissance d'investigation gouvernable.

Cette nuance est essentielle.

Les données publiques d'une blockchain représentent des faits.

Une investigation transforme progressivement ces faits en observations, en hypothèses, en corrélations, en preuves et finalement en connaissances exploitables.

Chacune de ces étapes constitue une transformation.

Chacune produit un nouvel état.

Chacune demeure explicable et reproductible.

Le Forensic Workshop applique ainsi les principes de la State Transformation Architecture à l'ensemble du processus d'investigation.

Les objets manipulés sont propres au domaine.

Transactions.

Adresses.

Clusters.

Événements.

Constatations (Findings).

Éléments de preuve (Evidence).

Cas d'investigation.

Leur nature diffère de celle rencontrée dans un compilateur de connaissance.

L'architecture demeure pourtant identique.

Les transformations restent explicites.

Les politiques d'investigation restent séparées des résultats qu'elles produisent.

Les objets de connaissance conservent leur traçabilité.

Les différentes représentations peuvent évoluer indépendamment les unes des autres.

Cette organisation permet à plusieurs expériences d'être construites à partir d'une même connaissance.

Un enquêteur pourra explorer les éléments de preuve.

Un analyste consultera des corrélations.

Un responsable recevra un rapport de synthèse.

Un système automatisé pourra exploiter les mêmes objets de connaissance pour produire des alertes ou assister une nouvelle investigation.

Ainsi, le Forensic Workshop ne constitue pas une application spécialisée.

Il représente un véritable atelier de production de connaissance.

Comme tout atelier fondé sur la State Transformation Architecture, il sépare la production de la connaissance, son organisation, ses transformations et ses différentes formes de diffusion.

Cette distinction lui permet d'évoluer indépendamment des technologies utilisées, des blockchains analysées ou des méthodes d'investigation retenues.

Le Forensic Workshop montre ainsi que les principes présentés dans cet ouvrage dépassent largement le domaine de l'édition.

Ils permettent d'organiser des systèmes dont la finalité n'est plus seulement de publier une connaissance, mais de la produire, de la gouverner et de la faire évoluer dans le temps.

Governance Publishing et le Forensic Workshop illustrent deux spécialisations de la State Transformation Architecture.

Ils poursuivent des objectifs différents.

Ils manipulent des objets de connaissance différents.

Ils produisent des expériences différentes.

Pourtant, ils reposent sur les mêmes principes architecturaux.

Cette observation conduit naturellement à une question.

Combien d'autres systèmes pourraient être construits selon cette approche ?

La réponse ne dépend pas d'un domaine particulier.

Elle dépend de l'existence d'une connaissance qui doit être produite, transformée, gouvernée et partagée.

Dès lors que cette connaissance évolue au travers d'états clairement identifiés, de transformations explicites et de règles gouvernables, un compilateur de connaissance devient envisageable.

Le domaine importe peu.

Une plateforme de recherche scientifique pourra compiler des résultats expérimentaux vers des publications ou des dossiers de validation.

Un système médical pourra transformer des observations cliniques en recommandations adaptées à différents acteurs.

Un environnement de formation pourra construire des parcours pédagogiques personnalisés à partir d'un même corpus de connaissances.

Une plateforme d'ingénierie pourra produire des documentations techniques, des procédures ou des dossiers de certification à partir d'objets de connaissance communs.

Dans chacun de ces exemples, les objets manipulés diffèrent.

Les expériences construites diffèrent.

Les artefacts produits diffèrent.

L'architecture demeure la même.

Cette généralité constitue l'une des forces de la State Transformation Architecture.

Elle ne propose pas un logiciel universel.

Elle propose une manière commune d'organiser les transformations de la connaissance.

Chaque compilateur pourra alors définir son propre langage métier.

Ses propres politiques.

Ses propres expériences.

Ses propres artefacts.

Tout en conservant une architecture capable de rendre chaque transformation explicable, reproductible et gouvernable.

Ainsi, les compilateurs de connaissance ne représentent pas une catégorie limitée de logiciels.

Ils constituent une nouvelle manière de concevoir les systèmes dont la mission est de faire évoluer une connaissance jusqu'à des usages adaptés à leurs utilisateurs.

Governance Publishing en constitue la première démonstration.

Le Forensic Workshop en illustre une seconde.

D'autres compilateurs apparaîtront naturellement à mesure que de nouveaux domaines adopteront cette manière d'organiser la connaissance.

Aucune architecture ne constitue une fin en soi.

Chaque génération de systèmes répond aux besoins de son époque.

Les systèmes d'information ont d'abord organisé des données.

Les systèmes transactionnels ont ensuite organisé des processus.

Les plateformes collaboratives ont facilité le partage de l'information.

Aujourd'hui, un nouveau défi apparaît.

Comment produire, transformer, gouverner et transmettre une connaissance dont la complexité ne cesse de croître ?

La State Transformation Architecture propose une réponse à cette question.

Elle ne cherche pas à remplacer les architectures existantes.

Elle leur apporte une nouvelle dimension.

Elle considère la connaissance comme un objet vivant.

Une connaissance possède des états.

Elle évolue par transformations.

Elle est gouvernée par des règles et des politiques explicites.

Elle peut donner naissance à des expériences différentes selon les usages auxquels elle est destinée.

Cette manière de concevoir les systèmes ouvre de nombreuses perspectives.

De nouveaux langages métier pourront être définis.

De nouveaux compilateurs de connaissance pourront apparaître.

De nouvelles expériences pourront être construites.

De nouveaux artefacts pourront être produits.

Ces évolutions ne remettront pas en cause les principes fondamentaux de l'architecture.

Elles en constitueront les spécialisations naturelles.

L'avenir de cette architecture ne dépend donc pas des technologies qui seront utilisées.

Les technologies évolueront.

Les formats disparaîtront.

Les interfaces seront remplacées.

Les usages continueront de changer.

Les principes qui permettent de transformer une connaissance de manière gouvernable, reproductible et explicable pourront, eux, continuer à s'appliquer.

C'est probablement là l'ambition la plus profonde de la State Transformation Architecture.

Ne pas proposer une solution pour un domaine particulier.

Proposer une manière durable de concevoir les systèmes qui manipulent la connaissance.

Le Forensic Workshop et Governance Publishing en constituent les premières démonstrations.

D'autres domaines construiront leurs propres langages métier.

D'autres compilateurs produiront leurs propres expériences.

D'autres artefacts rendront ces connaissances accessibles à leurs utilisateurs.

L'architecture, elle, restera fidèle à son principe fondateur.

Faire évoluer la connaissance par une succession de transformations dont chacune demeure explicable, gouvernable et reproductible.

Ce livre ne constitue donc pas la conclusion de cette démarche.

Il en marque le commencement.