# Les promesses derrière les pages : ingénierie de dsti.school, partie 2

Canonical HTML: https://dsti.school/fr/techblog/ingenierie-dsti-school-partie-2

This Markdown copy is generated from the same DSTI static-site build as the canonical HTML page. It is intended for machine readability and concise retrieval.

[DSTI TechBlog](https://dsti.school/fr/techblog) / Team DSTI

Team DSTI Gouvernance · identité · livraison

Un long article sur la manière dont le système derrière un site web statique est devenu une pratique de publication industrialisée : comment les langues, les liens, les identités, l’édition et la publication sont devenus des promesses organisationnelles que le domaine peut mémoriser, tester et tenir.

![Sébastien Corniglion](https://media.dsti.school/wp-content/uploads/2026/05/25131106/Sebastien-Corniglion-DSTI-School-of-Engineering.avif)

Sébastien Corniglion Directeur Général, doyen, cofondateur et enseignant en systèmes d’information, DSTI

31 août 2026 70 min de lecture Partie 2 sur 2

systemes-information gouvernance-contenu localisation donnees-liees ci-cd site-statique

Le fil conducteur

## D’une promesse organisationnelle à la preuve que le système peut faire respecter

01
Périmètre Définir où s’applique la promesse et où se situe sa limite.

02
Autorité Consigner la décision de l’organisation sous une forme que les personnes et les machines peuvent partager.

03
Contrôle Éprouver le résultat au regard de cette décision avant qu’il puisse avancer.

284 pages publiées

19 821 occurrences de liens internes

1 575 cas de test CI

DSTI TechBlog · Team DSTI

Une note sur la version, et sur l’honnêteté. Cet article décrit dsti.school tel qu’il était à la version V377, juste avant la V378 sous laquelle il est publié. Le domaine figé dans l’[instantané public](https://github.com/dsti-school/dsti-website-v377-public-snapshot), dont les chiffres figurent dans le panneau ci-dessus, est bien la V377. Préparer cette page pour la publication n’a pas été neutre : la soumettre aux propres règles du domaine a révélé des hypothèses qu’il a fallu reconstruire avant de pouvoir la publier — ce qui sied à un article consacré à la manière de faire tenir ses promesses à un système. Concrètement :

- Modèle de langue — la construction ne pouvait pas représenter une page qui existait en anglais avant ses traductions. Elle a été généralisée pour que le français, l’espagnol mexicain et le portugais brésilien suivent désormais une même règle — n’exister que là où leur traduction est rédigée —, supprimant une distinction qui traitait le français et l’espagnol différemment du portugais, ainsi que deux exceptions de chemin codées en dur. C’est la première page créée en anglais d’abord de cette manière, plutôt que « toutes les langues à la fois ». Et c’est plus sûr.

- Contrôle de cohérence & vérification du nombre de cartes — le contrôle d’intégrité du blog lui-même affirmait un catalogue figé au moyen de nombres fixes ; ceux-ci sont désormais dérivés du domaine.

Ces changements préservent le comportement — vérifiés page par page par rapport à la construction précédente — et sont verrouillés par sept nouveaux tests de régression et deux documents de gouvernance mis à jour.

[La partie 1 racontait la reconstruction de dsti.school](https://dsti.school/fr/techblog/refonte-dsti-school-printemps-2026) : le travail de terrain qui a précédé le code, le choix d’un [site web statique](https://en.wikipedia.org/wiki/Static_web_page) et les contrôles qui rendaient une publication vérifiable. Cette seconde partie commence là où ce récit s’achevait.

Une fois le nouveau site en place, la question difficile a dépassé la simple construction d’une page : comment l’organisation pouvait-elle tenir une promesse ?

Un tarif affiché en quatre langues doit rester le même tarif. Un enseignant relié depuis un article doit rester la même personne que l’enseignant figurant sur la [page des enseignants](https://dsti.school/fr/enseignants). Un collègue modifiant une [date d’admission](https://dsti.school/fr/admissions) doit pouvoir se concentrer sur la date pendant que la machinerie de publication fait son travail en dessous. Ce qu’un publicateur approuve doit être exactement ce qui atteint le domaine public. Et un ingénieur futur doit pouvoir découvrir, à partir du package lui-même, pourquoi ces règles existent, le raisonnement étant conservé au-delà d’anciens messages et d’incidents à demi oubliés.

Ce sont des promesses organisationnelles avant d’être des exigences techniques. L’ingénierie est venue ensuite.

Figure — la chaîne ADIS

**Figure:** La chaîne ADIS : une organisation nomme le besoin ; l’analyse fixe le quoi et la limite et résiste au comment ; la conception transforme cela en un plan (le comment) ; l’ingénierie construit et vérifie. Le code est une conséquence de la conception, non son moteur, et l’ordre ne s’inverse jamais.

> **Figure caption:** La chaîne ADIS : l’organisation nomme le besoin, l’analyse fixe le quoi et la limite, la conception le transforme en comment, l’ingénierie construit et vérifie.

C’est l’ordre enseigné en [Analysis & Design of Information Systems (ADIS)](https://dsti.school/fr/enseignants#prof-CORNIGLION) à DSTI School of Engineering. L’organisation énonce le besoin. L’analyse établit ce qui doit tenir et où se situe sa limite. La conception décide comment le système le tiendra. L’ingénierie construit et vérifie le résultat. La discipline plus large s’énonce simplement : le code est une conséquence de la conception, et la conception est une conséquence de la commande de l’organisation.

Cette séquence est facile à réciter et étonnamment difficile à respecter. Le travail technique crée sa propre dynamique. Dès qu’une équipe sait construire quelque chose, il devient tentant de laisser la technologie disponible définir le problème. Un schéma de base de données devient le modèle de l’organisation parce qu’il existe déjà. Un système de déploiement se dote de cérémonies parce que sa première mise en œuvre en a eu besoin. Un outil de traduction se met à décider du vocabulaire académique parce qu’il produit rapidement des phrases plausibles.

L’ADIS nous demande d’aller dans l’autre sens. Qu’est-ce qui doit rester vrai ? Qui a l’autorité pour en décider ? Quelle limite l’exigence franchit-elle ? Quelle preuve nous permettrait de refuser un résultat incorrect ? Ce n’est qu’une fois ces questions réglées que nous choisissons une représentation ou un outil.

Le site suit désormais cet ordre. Son ingénierie se lit à travers trois idées récurrentes :

- un périmètre , qui définit la portée de la promesse et sa limite ;

- une autorité , qui consigne la décision de l’organisation sous une forme partageable par les personnes et les machines ;

- un contrôle , qui refuse un résultat contredisant cette autorité.

La promesse est l’unité d’ingénierie.

## 01 Quand l’exigence a changé

La première exigence était modeste : [DSTI School of Engineering](https://dsti.school/fr/) avait besoin d’un site web modernisé.

La première méthode de travail y correspondait. Les pages étaient construites au fil de conversations avec ChatGPT et échangées sous forme d’archives ZIP. Pour une brochure assemblée par une seule personne, c’était rapide et suffisant. L’archive contenait le résultat visible ; la conversation contenait l’essentiel du raisonnement ; la personne qui avait mené le travail reliait les deux.

L’organisation a ensuite commencé à demander au site de garantir les relations derrière ce qu’il affichait. Cette exigence plus large appelait une autre méthode.

Les mêmes informations d’admission pouvaient-elles rester cohérentes d’une langue à l’autre ? Un changement pouvait-il être confié à un autre collègue avec son contexte déjà conservé ? Une publication pouvait-elle être refusée parce qu’une déclaration cachée, lisible par machine, avait dérivé alors même que la page paraissait correcte ? Pouvions-nous prouver que les octets approuvés en pré-production étaient bien les octets publiés ensuite ? Un rédacteur pouvait-il travailler en toute sécurité pendant que le déploiement restait la responsabilité du système de publication ?

La distinction est importante. Un dossier de fichiers peut contenir une réponse correcte. Une autorité opérationnelle doit en outre expliquer pourquoi la réponse est correcte, qui est habilité à la modifier et quel changement futur l’invaliderait. Une transcription de conversation conserve une discussion ; le package a besoin que ses décisions prennent une forme que les personnes et les machines peuvent interroger, tester et interpréter de manière cohérente.

La mémoire du projet a donc été déplacée dans un unique dépôt gouverné utilisant [Git](https://en.wikipedia.org/wiki/Git), un système de gestion de versions distribué. La gestion de versions enregistre les modifications apportées à un ensemble de fichiers et l’ordre dans lequel elles ont été acceptées. Sa valeur, ici, tient à ce qu’elle donne à l’organisation une histoire commune et un point précis à partir duquel toute construction peut commencer ; la vérité dépend toujours des autorités et des contrôles appliqués à cette histoire.

Dans ce package, Git est devenu la mémoire du package qui fait autorité — l’un de ses composants étant les [Engineering Principles](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/documentation/governance/ENGINEERING_PRINCIPLES.md). Cela signifie bien plus que conserver le code source. Cela comprend les règles, les schémas, les autorités de traduction, les descriptions d’outils, les tests et les documents opérationnels nécessaires pour comprendre et reproduire le système. Le dépôt est un point de départ commun pour les personnes, les agents et les pipelines.

On est proche de l’idée d’une [source unique de vérité](https://en.wikipedia.org/wiki/Single_source_of_truth), avec une réserve importante. Le dépôt gouverne le package et la version candidate que nous entendons construire. Le domaine en production actuel existe en propre, et un instantané de restauration consigne l’état public précédent. La source, le package opérationnel et le prédécesseur en production ont chacun une finalité distincte ; garder ces finalités séparées a supprimé une source de sur-ingénierie antérieure.

Le modèle mûr est délibérément moins spectaculaire :

- le package et ses règles de fonctionnement sont gouvernés dans Git ;

- le contenu maintenu et la projection de publication sont gouvernés dans Git ;

- le domaine en production précédent est conservé indépendamment comme unique limite de restauration opérationnelle.

Cette séparation garde l’histoire utile tout en permettant à chaque action de suivre son autorité réelle. Une correction de contenu peut devenir un correctif de même version. Une nouvelle version publique peut faire avancer à la fois l’identité et la date de publication. Un déploiement capture le domaine en production actuel avant de le remplacer ; la limite de restauration reflète donc ce qui était véritablement public à ce moment-là.

La leçon plus large dépasse le « utilisez Git » : une garantie a besoin d’un lieu durable où exister. Chaque nouvelle promesse organisationnelle a acquis un périmètre déclaré, une autorité capable de s’en souvenir et un contrôle capable de refuser de l’enfreindre. Le reste de l’architecture découle de ce choix.

## 02 La même école, en quatre langues

[DSTI School of Engineering](https://dsti.school/fr/) est une école française dont les étudiants et les familles viennent bien au-delà de la France. Chaque lecteur doit pouvoir rencontrer l’école dans une langue pensée pour lui.

Le domaine compte donc quatre [paramètres régionaux](https://en.wikipedia.org/wiki/Locale_%28computer_software%29) gouvernés. Un paramètre régional est plus précis qu’un nom de langue : il associe une langue aux conventions régionales qui influencent le vocabulaire, la ponctuation et l’usage attendu. Les quatre variantes sont l’anglais britannique comme source, le français de France standard, l’espagnol mexicain et le portugais brésilien. L’espagnol mexicain sert un public latino-américain à travers une norme régionale cohérente ; le portugais brésilien offre aux lecteurs lusophones leur propre édition naturelle. Ces normes explicites donnent aux rédacteurs humains et aux systèmes de traduction des instructions plus précises que les étiquettes générales « français », « espagnol » et « portugais ».

Ce travail relève de la [localisation](https://en.wikipedia.org/wiki/Language_localisation) : il préserve à la fois le sens et la manière dont un lecteur s’attend à ce que ce sens soit exprimé. Une phrase fidèle peut malgré tout sonner « traduite », tandis qu’une phrase naturelle peut discrètement changer un fait. Les deux dimensions comptent.

Figure — une source, quatre paramètres régionaux

**Figure:** Une source, quatre paramètres régionaux de premier ordre : anglais britannique (en-GB, la source), français standard de France (fr), espagnol mexicain (es-MX) et portugais brésilien (pt-BR), reliés par des hreflang réciproques avec x-default. Les slugs ne sont jamais traduits automatiquement, la substance du programme reste en anglais canonique dans chaque paramètre régional, et chaque cible passe par une traduction gouvernée et une relecture humaine.

> **Figure caption:** Une source, quatre paramètres régionaux de premier ordre : source en-GB, fr, es-MX et pt-BR, reliés par des hreflang réciproques ; la substance du programme reste en anglais canonique.

### D’un fichier générateur unique à un système d’autorités

En juin, la gouvernance de la traduction tenait dans un seul fichier texte : `translations_principles_generator.txt`. Son titre complet l’appelait « DSTI translation & localisation principles — generator », et sa première instruction était littéralement un message de contexte que l’on pouvait coller dans une nouvelle conversation. Il était utile. Il indiquait au modèle de langue suivant que l’anglais britannique était la source, définissait le français et l’espagnol mexicain, exigeait une passe fidèle suivie d’une passe de naturel, protégeait le balisage et les noms officiels, et consignait le vocabulaire récurrent.

Il relevait aussi de la manière dont le projet fonctionnait à l’époque. Le fichier expliquait quelle archive ZIP ouvrir en premier, où placer les résumés associés et quelles colonnes temporaires un classeur Excel devait utiliser pour évaluer et renvoyer les traductions. Des règles de langue durables et une procédure opérationnelle temporaire occupaient le même document. Le portugais brésilien rejoindrait plus tard l’ensemble comme paramètre régional cible à part entière.

Ce générateur transférait efficacement le contexte d’une conversation à l’autre. Une autorité organisationnelle complète en exigeait davantage : un futur opérateur devait distinguer les règles de langue actuelles, une procédure de classeur abandonnée et les éléments issus d’un seul exercice de traduction, répartis sur 481 lignes. La conception suivante a donc ajouté une forme validée et une gouvernance égale pour chaque paramètre régional.

Le système actuel sépare ces responsabilités tout en conservant le fichier d’origine dans l’historique Git. La hiérarchie opérationnelle active est explicite :

- [LANGUAGE_AUTHORITY.md](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/documentation/translation/LANGUAGE_AUTHORITY.md) et [LANGUAGE_AUTHORITY.json](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/documentation/translation/LANGUAGE_AUTHORITY.json) déclarent l’anglais britannique comme source normale, nomment les trois paramètres régionaux cibles et indiquent quelle autorité l’emporte lorsque les fichiers divergent.

- [locale-profiles.json](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/CONTENT_MANAGER/source/APP_SETTINGS/locale-profiles.json) donne au français de France, à l’espagnol mexicain et au portugais brésilien les mêmes champs lisibles par machine : code de langue du document, paramètre régional Open Graph, autorité de routes, interface de rédaction et relecture humaine obligatoire.

- Le schéma commun [LOCALE_LANGUAGE_GUIDANCE.schema.json](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/documentation/translation/LOCALE_LANGUAGE_GUIDANCE.schema.json) définit ce que doit contenir chaque fichier de directives de paramètre régional.

- [FR_LANGUAGE_GUIDANCE.json](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/documentation/translation/FR_LANGUAGE_GUIDANCE.json), [ESMX_LANGUAGE_GUIDANCE.json](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/documentation/translation/ESMX_LANGUAGE_GUIDANCE.json) et [PTBR_LANGUAGE_GUIDANCE.json](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/documentation/translation/PTBR_LANGUAGE_GUIDANCE.json) portent les décisions linguistiques réelles pour chaque paramètre régional.

- La table de correspondance page–paramètre régional consigne quelle page source maintenue correspond à quelle page traduite et quelle route chacune possède.

- Des valeurs stables `data-dsti-element-id` et `data-dsti-source-id` relient un élément traduit à l’élément anglais qu’il traduit.

Les fichiers de directives de paramètre régional sont des autorités délibérément structurées. Leurs champs séparent le registre, la mise en forme, la préservation, les sources et la terminologie. Une entrée terminologique peut consigner le concept anglais, les choix contextuels admis, les formes déconseillées et la raison de la décision. Tout ce que contient le fichier constitue une directive actuelle, et chaque paramètre régional suit un modèle uniforme.

Cela compte en pratique. « Digital jobs », par exemple, se comprend traduit littéralement, mais le résultat littéral peut laisser entendre un travail effectué en ligne. Le sens visé concerne les carrières dans le secteur technologique. L’autorité pour l’espagnol mexicain consigne donc `empleos en el sector tecnológico` et des solutions contextuelles. L’autorité pour le portugais brésilien préfère `profissões na área de tecnologia`, `empregos na área de tecnologia` ou `carreiras em tecnologia`, selon que la phrase porte sur des professions, des postes vacants ou des parcours de carrière. La découverte de la session de traduction vit désormais comme une décision réutilisable dans l’autorité.

La terminologie scientifique se résout d’abord par le concept. Le traducteur part du concept anglais, utilise les liens interlangues de Wikipedia pour découvrir le terme établi dans la langue cible, vérifie l’usage professionnel et consigne le choix contextuel. Les noms officiels gardent la priorité : un programme, un cours, une unité d’enseignement nommée, un produit, une technologie ou un jeton machine de DSTI reste protégé.

La première limite de conception reste donc claire. Le récit humain de DSTI voyage : le [parcours d’admission](https://dsti.school/fr/admissions), l’expérience des [étudiants internationaux](https://dsti.school/fr/etudiants-internationaux), l’environnement de l’école et les explications autour d’un [programme](https://dsti.school/fr/programmes). La substance académique conserve son identité anglaise canonique : les noms officiels de programmes, les noms de cours, les descriptions de cours et les unités d’enseignement nommées restent cohérents dans chaque paramètre régional.

Cela peut sembler inhabituel au premier abord. Une page en portugais peut contenir un intitulé de cours en anglais au sein d’un portugais brésilien par ailleurs naturel. C’est délibéré. L’intitulé identifie un objet académique unique, utilisé dans les emplois du temps, les dossiers et les autorités de programmes. Le traduire créerait une seconde étiquette dont la relation avec le cours officiel devrait être maintenue indéfiniment. L’explication environnante appartient à la langue du lecteur ; l’identité académique appartient à l’autorité du programme.

### Ce qu’implique désormais la traduction d’une page

Le processus commence par une paire source/cible maintenue, gouvernée comme une seule unité éditoriale.

- Fixer la source et le périmètre. Le travail part d’un commit Git propre. L’autorité page–paramètre régional identifie la source en anglais britannique et la cible française, espagnole ou portugaise.

- Charger l’autorité du paramètre régional cible. Le traducteur lit la politique commune et les directives [JavaScript Object Notation (JSON)](https://en.wikipedia.org/wiki/JSON) de la cible : registre, adresse au lecteur, présentation des nombres et des devises, formes protégées, terminologie récurrente et solutions contextuelles.

- Traduire pour la fidélité. La première passe préserve chaque fait, nuance et accent tout en résistant aux ajouts explicatifs ou à l’interprétation éditoriale. Les programmes, cours et technologies officiels restent inchangés.

- Réécrire pour le naturel. La seconde passe supprime les calques, les faux amis, l’ordre des mots de la langue source et les dérives de registre. L’espagnol mexicain emploie `tú` et évite le vocabulaire propre à l’Espagne ; le portugais brésilien recourt à des tournures brésiliennes naturelles ; le français de France reste moderne, neutre et sans affectation régionale.

- Protéger la structure au moyen de Dsti.ContentInventory. Le texte lisible peut se trouver à l’intérieur de `<span>`, de `<strong>` ou de liens, et l’inventaire l’expose au rédacteur comme contenu identifié, distinct du [HyperText Markup Language (HTML)](https://en.wikipedia.org/wiki/HTML) environnant. Dsti.ContentInventory relie la valeur à son `data-dsti-element-id` stable et, pour une traduction, à la lignée source portée par `data-dsti-source-id`. Le rédacteur modifie la valeur identifiée tandis que les balises, attributs, identifiants et routes gouvernées restent intacts. Le rôle de l’inventaire est l’identification ; l’autorité de langue et les deux passes humaines gouvernent la traduction elle-même. Les changements structurels et sémantiques se font explicitement dans le HTML maintenu, tandis que le Markdown généré et les fichiers de distribution servent de surfaces de relecture.

- Relire ce que produit la construction. Le jumeau Markdown généré de la page rend la relecture du texte rapide. Le HTML est ensuite inspecté là où comptent les métadonnées, les liens, le balisage imbriqué ou le [JavaScript Object Notation for Linked Data (JSON-LD)](https://en.wikipedia.org/wiki/JSON-LD). Un humain demeure responsable du sens et du naturel.

- Préparer le domaine. La construction gouvernée régénère tout et exécute le contrôle de traduction du domaine sur la version candidate construite complète — la forme exacte éligible à la publication.

La page est traitée d’un bout à l’autre comme un objet lié à sa source. Si la traduction portugaise d’un paragraphe échoue, le rapport identifie le `data-dsti-element-id` portugais, le `data-dsti-source-id` anglais, et les deux valeurs. Le rédacteur peut revenir directement à l’élément maintenu exact qui doit être corrigé, sans avoir à chercher à la ligne 417 d’une sortie minifiée.

### Ce que le contrôle de traduction prouve réellement

Le contrôle à l’échelle du domaine énumère chaque groupe de pages complètes gouverné, sur le site et sur les sous-domaines connexes, puis évalue chaque paire source/cible matérialisée. Sur une version candidate récente, cela représentait 211 paires réparties dans 73 groupes. Il s’exécute au sein de `prepare`, car seule la version candidate construite contient la forme complète qui serait publiée.

Le contrôle vérifie un ensemble délibérément restreint d’invariants déterministes :

- la `<html lang>` cible et le paramètre régional Open Graph correspondent à son profil ;

- les URL canoniques source et cible forment une paire de routes approuvée ;

- la lignée d’éléments stable est cohérente là où la lignée exacte s’applique ;

- les blocs `<pre>` lisibles par machine conservent leurs valeurs et leur structure gouvernées ;

- les termes protégés de programme, de produit, de mode d’études et de technologie subsistent sur toute la page.

Si l’un de ces contrôles échoue, la version candidate est purgée et reste donc inéligible à la publication. Une liste de tâches Markdown et un rapport JSON lisible par machine demeurent en dehors de la version candidate. L’opérateur corrige la source maintenue et relance `prepare` ; la nouvelle préparation remplace la tentative précédente et présente une seule version candidate actuelle.

Le contrôle évalue une cohérence déterministe. Les relecteurs humains jugent si une phrase est idiomatique, si `tú` paraît accueillant dans son paragraphe précis, et si une explication traduite porte l’accent de la source. La présentation des nombres et des devises reste elle aussi contextuelle : les formats locaux, les nombres écrits en toutes lettres, les dates et les intervalles produisaient trop de faux positifs pour une règle mécanique neutre du point de vue du paramètre régional. Les nombres critiques qui relèvent d’un domaine gouverné — une date d’admission, un tarif ou un total de cursus — sont protégés par l’autorité et le contrôle de ce domaine ; la relecture linguistique reste responsable de leur expression en prose.

Cette répartition est plus utile qu’un « score de traduction » universel. La machine protège ce qui peut être énoncé exactement. L’autorité de langue guide ce qui dépend du contexte. Un humain décide si le résultat est à la fois fidèle et digne d’être lu.

Les quatre pages doivent aussi s’identifier les unes aux autres auprès des machines. Chacune possède son propre [Uniform Resource Locator (URL)](https://en.wikipedia.org/wiki/URL), une adresse canonique qui déclare l’URL publique préférée, ainsi que des références réciproques vers les autres langues. Les moteurs de recherche connaissent couramment ces relations entre langues grâce à `hreflang`. Le titre de la page doit s’accorder avec son titre de partage social exprimé au moyen du [Open Graph protocol](https://en.wikipedia.org/wiki/Open_Graph). Ses données structurées doivent donner à la page portugaise son identité et sa route portugaises.

Ce sont des déclarations opérationnelles autant qu’éditoriales. Un lecteur peut voir un portugais correct tandis qu’un robot d’indexation se voit annoncer que la page est en anglais, ou tandis que le sélecteur de langue renvoie vers une ressource anglaise. La cohérence linguistique doit donc englober ensemble le texte visible, les liens et les métadonnées lisibles par machine.

Ajouter un paramètre régional étend chaque relation à laquelle sa page participe : titre, lien alternatif, bloc de données structurées, redirection et renvoi. Chaque paramètre régional cible entre donc dans le même schéma, le même flux de paire de pages et la même relecture en deux passes. L’ensemble du domaine est vérifié dans chaque paramètre régional disponible ; les éléments peuvent alors montrer qu’un défaut est propre à un paramètre régional. La langue devient une dimension du diagnostic, tandis que le défaut lui-même reste guidé par les faits.

L’autorité est désormais la famille de paramètres régionaux, les fichiers de langue, la carte des routes et la lignée source agissant de concert. La limite reste la ligne entre l’explication localisable et la substance académique canonique. Le contrôle déterministe protège ce que les machines peuvent savoir ; les deux passes humaines protègent ce que seuls les lecteurs peuvent juger.

La langue montre la méthode à une limite. La même méthode devient plus exigeante lorsque les relations couvrent l’ensemble du domaine.

## 03 La cohérence est une propriété du domaine

Le système public est plus vaste que le site principal. Il comprend quatre familles connexes — facts, information, Sophia et awareness — chacune avec ses propres routes et variantes linguistiques. Prises ensemble, la publication gouvernée contient 742 fichiers déployables répartis sur 284 pages HTML, 285 blocs JSON-LD et 363 redirections gérées.

Le HTML décrit la structure d’une page web. Le JSON-LD exprime des entités et des relations dans un graphe lisible par machine tout en restant intégrable dans cette page. Les deux vues peuvent diverger même lorsque le navigateur affiche quelque chose d’attrayant. Le programme visible peut nommer un enseignant tandis que le JSON-LD en nomme un autre. Une route traduite peut afficher du français tout en annonçant une adresse canonique anglaise. Ces défauts de site peuvent rester visuellement plausibles.

Les totaux du domaine décrivent son échelle. La cohérence vient de ce qu’une construction future s’arrête lorsque l’une des relations enregistrées se rompt.

Figure — la surface de cohérence

**Figure:** La surface de cohérence : une grille des cinq familles (le site web principal plus facts, info, Sophia, awareness) face aux quatre paramètres régionaux, indiquant quel paramètre régional chaque famille livre ; avec les totaux du domaine entier — 742 fichiers déployables, 284 pages, 285 blocs JSON-LD, 363 redirections, 211 paires de traduction réparties sur 73 groupes, et 11 contrôles de construction nommés. Chaque cellule est une promesse ; une promesse rompue fait échouer la construction.

> **Figure caption:** La surface de cohérence : le site web et les familles de supports croisés avec quatre paramètres régionaux, gouvernés par des contrôles à l’échelle du domaine.

Un vérificateur de page et un vérificateur de domaine répondent à des questions différentes. Le vérificateur de page lit un document, évalue ses liens, ses métadonnées et ses énoncés sémantiques, puis passe au suivant. Sa méthode délibérément bornée est prévisible : prendre une page, inspecter les références internes à DSTI qu’elle contient, vérifier leur cible et leur langue, consigner le résultat, continuer. Il consomme l’autorité de domaine fournie et reste dans la page courante ; la construction récursive du graphe se situe en dehors de cette opération.

À la couche source gouvernée, l’inventaire recense 2 563 références internes visibles et 4 140 références internes au total lorsqu’on inclut les déclarations canoniques, le `hreflang`, l’Open Graph et le JSON-LD. Ces chiffres décrivent les relations que le système doit préserver ; le nombre d’occurrences du domaine construit, indiqué dans le panneau, décrit chaque endroit où ces relations sont matérialisées.

La vue à l’échelle du domaine demande ensuite si ces résultats de pages indépendants concordent entre eux. Les liens internes doivent aboutir à la cible et au paramètre régional voulus. Les liens relatifs s’emploient au sein d’un même hôte, tandis que les liens entre le site et un contenu connexe utilisent des adresses complètes, car la frontière d’hôte a un sens. Les références média doivent utiliser l’hôte média gouverné, sauf pour les données délibérément intégrées en ligne. Les routes canoniques et alternatives doivent concorder. Les données structurées d’une page traduite doivent identifier cette page traduite dans son propre paramètre régional. Le contenu des fiches de cours doit rester en anglais canonique. Les titres de page et leurs jumeaux Open Graph et sociaux doivent rester un seul titre. Les sitemaps et le `llms.txt` — l’index concis du domaine destiné aux [grands modèles de langage (LLM)](https://en.wikipedia.org/wiki/Large_language_model) — doivent porter la date de publication scellée, et les fichiers de langue des contenus connexes doivent référencer tous leurs équivalents gouvernés.

Le vérificateur combine l’autorité des paramètres régionaux avec une découverte indépendante des pages qui existent réellement. Si une page maintenue est absente de l’autorité, la découverte rend l’écart visible afin que l’autorité puisse être mise à jour. Cet appariement prouve la cohérence de l’ensemble du domaine découvert autant que de l’ensemble enregistré.

La distinction entre règles locales et globales compte. « Ce lien aboutit » est local à la page. « Ce lien aboutit à la bonne langue partout où cette cible dispose d’une édition localisée » exige la connaissance de l’autorité du domaine. « Cette source média utilise le bon hôte » est local. « Chaque identité média publique est représentée de manière cohérente dans les métadonnées de page et les données structurées » traverse les documents. Un bon contrôle énonce quel type d’affirmation il porte.

Le contrôle des heures de programme fournit un exemple chiffré du même principe. Le [MSc in Data Analytics with AI](https://dsti.school/fr/msc-data-analytics-ai) affichait 835 heures comme volume phare, alors que sa propre structure de composants totalisait 725 heures . Les quatre paramètres régionaux répétaient 835 ; une comparaison entre langues, à elle seule, voyait donc un accord parfait. Les pages étaient uniformément fausses ; le total visible est désormais corrigé à 725 heures dans chaque paramètre régional.

Le contrôle des heures de programme qui en résulte est donc à la fois intra-page et inter-langues. Il tire sa portée de la lignée de contenu stable et des formes trouvées dans les pages, et il reconnaît que les programmes expriment le volume de différentes manières. Les pages MSc et Executive comparent un chiffre phare à leur total d’enseignement déclaré ; le [Bachelor of Science (BSc)](https://dsti.school/fr/bsc-informatique-ingenierie) vérifie l’énoncé `teaching + support = total` de chaque année tout en gardant son chiffre phare en [European Credit Transfer and Accumulation System (ECTS)](https://en.wikipedia.org/wiki/European_Credit_Transfer_and_Accumulation_System) hors d’une règle d’heures. C’est ce qu’ajoute un invariant de domaine : un énoncé explicite des nombres qui doivent concorder et des raisons.

L’étape de préparation du package regroupe ces préoccupations en contrôles explicites, chacun capable de rapporter la relation qu’il protège. Parmi eux :

- la complétude de la source et du domaine généré ;

- la cohérence des paramètres régionaux et des routes alternatives ;

- la cohérence des URL internes et des hôtes de contenus connexes ;

- la validation sémantique et [Schema.org](https://en.wikipedia.org/wiki/Schema.org) ;

- l’équivalence ContentInventory ;

- les contrôles de fidélité de traduction et de terminologie ;

- la cohérence du sitemap, du robots, du `llms.txt` et du jumeau Markdown ;

- les règles d’hôte média et de formats de métadonnées acceptables ;

- l’équivalence [JavaScript](https://en.wikipedia.org/wiki/JavaScript) et [Cascading Style Sheets (CSS)](https://en.wikipedia.org/wiki/CSS) avant et après optimisation ;

- la validation des schémas et de la configuration ;

- la relecture visuelle des pages modifiées.

Le CSS gouverne la présentation : typographie, espacement, mise en page adaptative et le comportement qui transforme le même HTML en une interface pour ordinateur portable ou pour téléphone. Son optimisation est acceptée lorsque le package prouve que la projection optimisée reste équivalente à la source gouvernée dans le cadre du contrat défini ; l’achèvement d’un [minifier](https://en.wikipedia.org/wiki/Minification_%28programming%29) — un outil qui retire les caractères superflus pour réduire la taille du fichier — n’est que l’étape de transformation.

Ces contrôles répondent à une question différente de celle des validateurs de documents décrits dans la partie 1. La conformité HTML établit qu’un document est syntaxiquement valide. Les nouveaux contrôles opèrent sur le domaine comme un ensemble de documents liés, établissant qu’un contenu connexe portugais renvoie vers le guide portugais et que la même date d’admission apparaît partout où elle le doit.

Le vérificateur classe chaque échec selon l’autorité nécessaire pour le résoudre. Certains révèlent un contenu manquant. D’autres révèlent une autorité incomplète. Un cours peut présenter une collision de code historique dont la résolution exige une décision académique ; une modification mécanique serait insuffisante. Un rapport précis soumet chaque cas à la bonne autorité.

C’est pourquoi le système peut être cohérent et avoir néanmoins besoin de lecteurs. Les contrôles prouvent les liens, les identités, les dates et les relations de langue déclarées. Les lecteurs humains apprécient le ton, l’accent et la qualité pédagogique. La cohérence mécanique fournit le socle sur lequel la qualité éditoriale peut reposer.

## 04 Une modification doit nommer ce qu’elle change

Dès que plusieurs personnes et agents peuvent modifier le domaine, un modèle de contenu durable doit identifier directement la valeur visée. « Ouvrir le fichier et trouver le texte » lie un rédacteur au balisage, favorise des changements accidentels autour de celui qui est voulu, et rend le travail concurrent difficile à raisonner.

La publication web traditionnelle masque souvent cette complexité derrière un [Content Management System (CMS)](https://en.wikipedia.org/wiki/Content_management_system). Un CMS tel que [WordPress](https://en.wikipedia.org/wiki/WordPress) protège un rédacteur du HTML brut au moyen de champs, d’aperçus et de commandes de publication. DSTI a conservé son architecture statique et a répondu au même besoin humain par une surface compréhensible pour modifier les dates, les libellés et les enregistrements, tandis que la structure interne de la page reste protégée.

Le résultat est une surface de contenu identifiée. Chaque élément modifiable possède une identité gouvernée stable, et une modification nomme directement cette identité. L’élément source anglais porte sa propre identité ; les éléments traduits renvoient à cette identité source par leur lignée. Un paragraphe français peut se déplacer au sein d’une page tout en restant le même objet éditorial.

Les dates d’admission, les fiches partenaires, les médias, les redirections et les témoignages d’étudiants disposent chacun d’une opération gouvernée avec ses propres entrées et préconditions. Les changements plus importants sont organisés en lots de travaux, dans l’ordre des dépendances, avant que l’édition ne commence. La forme lisible par machine est un [directed acyclic graph (DAG)](https://en.wikipedia.org/wiki/Directed_acyclic_graph) : un ensemble de tâches reliées par des dépendances à sens unique. Sa structure acyclique donne à chaque étape de construction un prédécesseur résoluble, tandis que le graphe montre ce qui peut avancer en parallèle et quelle autorité doit être tranchée en premier.

Figure — ContentInventory comme colonne vertébrale

**Figure:** Dsti.ContentInventory comme colonne vertébrale : un classeur de forme Excel est devenu un inventaire ancré par id qui associe chaque nœud de texte éditable à un identifiant stable, alimentant des primitives de contenu gouvernées et des contrôles à échec fermé. L’inventaire permet aux modifications de contenu de cibler des valeurs identifiées tandis que les changements de structure, de liens et de sémantique restent un travail de source explicite.

> **Figure caption:** ContentInventory : une surface d’édition en forme de classeur est devenue un inventaire ancré par id qui alimente des opérations de contenu gouvernées.

Dsti.ContentInventory est la colonne vertébrale de ce dispositif. Il a commencé comme un remplacement, de la forme de [Microsoft Excel](https://en.wikipedia.org/wiki/Microsoft_Excel), pour l’édition rapide sous WordPress, et est devenu la carte reliant le contenu lisible et les éléments de page stables. Le tableur reste utile précisément parce qu’il est familier. L’ingénierie réside dans ce qui l’entoure désormais.

Une session d’édition est liée à un état Git propre, à un schéma — une définition, lisible par machine, de la structure autorisée —, à un rédacteur et à un périmètre explicite. Un périmètre exclusif empêche deux sessions de revendiquer discrètement le même contenu. Les jumeaux [Markdown](https://en.wikipedia.org/wiki/Markdown) générés fournissent une surface de lecture en texte brut, tandis que le HTML maintenu reste la source des changements structurels et sémantiques. La préparation garde le classeur couplé aux pages en vérifiant que le classeur généré reste substantiellement équivalent au classeur canonique gouverné.

Cette distinction évite un échec bien connu. Si un fichier généré est modifié à la main, le changement peut sembler correct jusqu’à ce que la construction suivante le régénère à partir de la source et efface le travail. Une opération gouvernée modifie la source maintenue, puis laisse la construction produire la distribution, les jumeaux Markdown des pages et les preuves de l’inventaire. La sortie de construction sert de surface d’inspection ; la source maintenue reste la surface d’édition.

L’outil lui-même devait mûrir avec le modèle de contenu. La partie 1 décrivait un binaire .NET 8 committé. [.NET](https://en.wikipedia.org/wiki/.NET) est le cadriciel logiciel multiplateforme de Microsoft ; l’outil ContentInventory actuel est construit à partir de la source gouvernée avec le [software development kit (SDK)](https://en.wikipedia.org/wiki/Software_development_kit) .NET 10, de sorte que le dépôt porte la source à la place d’un binaire compilé. La reconstruction à partir de la source s’est accompagnée de la correction d’un défaut d’identification en portugais brésilien : les éléments nouvellement identifiés avaient été créés avec `pt.br.` alors que la lignée gouvernée est `pt.`. La construction actuelle à partir de la source produit systématiquement la forme gouvernée `pt.`.

C’est un exemple utile, car la gouvernance s’étend aussi aux outils derrière le site visible. Un outil qui identifie le contenu peut créer une dérive tout aussi sûrement qu’un rédacteur. Une fois cela compris, l’outil est entré dans le même modèle d’autorité et de contrôle que les pages qu’il sert.

La discipline d’édition inclut un travail HTML direct pour les changements véritablement structurels : ajouter une relation en JSON-LD, séparer les enseignants principaux des enseignants de soutien sur une fiche de cours, ou introduire une commande accessible. Ces changements relèvent de la source maintenue et exigent un ingénieur. La surface identifiée rend la limite explicite et réserve l’édition de la forme d’un tableur au contenu qu’elle peut représenter sans risque.

### Observer le résultat dans une limite de preuve définie

La présentation visuelle intervient à la fin d’une opération de contenu, sur les octets éligibles à la publication. Check User Interface (Check UI) rend les pages modifiées au moyen de l’[browser automation](https://en.wikipedia.org/wiki/Browser_automation) avec [Playwright](https://en.wikipedia.org/wiki/Playwright_%28software%29). L’automatisation de navigateur pilote un véritable moteur de rendu à des tailles de fenêtre d’affichage prédéfinies, ce qui permet au package d’inspecter ce qu’un lecteur recevrait sur un ordinateur portable compact, un écran plus grand, une tablette ou un téléphone.

Les pages modifiées sont rendues sur neuf fenêtres d’affichage critiques par défaut, ou sur l’ensemble des vingt fenêtres gouvernées lors d’une relecture complète. Une demande portant sur une seule page inclut cette page dans chaque paramètre régional disponible. Les contrôles couvrent ce qui peut être établi de manière déterministe : débordement, contenu échappé ou tronqué, identifiants en double, noms de commandes accessibles manquants, contraste du texte sur des fonds déterminables, navigation cassée, ressources manquantes et erreurs d’exécution.

Les preuves sont utiles précisément parce que leur portée est énoncée. Check UI fournit des preuves de navigateur déterministes pour les défauts listés ; un audit d’accessibilité complet et une relecture visuelle humaine couvrent la composition, une lisibilité confortable et la question de savoir si une illustration communique bien l’idée voulue. Un détecteur de chevauchement générique peut aussi rencontrer un mouvement légitime, comme un élément de menu intégré à la page qui entre ou sort de la fenêtre d’affichage à mesure que le lecteur défile. Le système isole cette classe de faux positifs défendable tout en continuant à signaler les autres chevauchements.

Une exécution locale signale lorsqu’une référence en production digne de confiance est indisponible, gardant ses preuves honnêtes. La relecture locale peut viser l’ensemble du domaine ou un ensemble de pages choisi ; le contrôle d’intégration continue gouverné applique le périmètre des pages modifiées de la version candidate avant la pré-production. Les preuves visuelles éclairent la décision humaine, qui reste le jugement final sur la présentation.

Le principe est le même partout : le système énonce exactement ce qu’il peut prouver et confie le jugement restant à l’autorité qui lui revient.

## 05 La même chose doit rester la même chose

Un site écrit pour des personnes peut tolérer la répétition. Le même intitulé de cours peut figurer sur quatre pages de programme et sur plusieurs fiches d’enseignants. Un graphe lisible par machine doit trancher si ces occurrences décrivent la même chose.

L’idée pertinente vient du [Web sémantique](https://en.wikipedia.org/wiki/Semantic_Web), présenté plus en profondeur dans l’article de DSTI [Web sémantique & données liées : rendre le Web lisible par les machines](https://dsti.school/fr/techblog/web-semantique-donnees-liees) : les ressources web peuvent exprimer des documents, des entités identifiées et des relations typées. Un [graphe de connaissances](https://en.wikipedia.org/wiki/Knowledge_graph) représente ces entités comme des nœuds et leurs relations comme des arêtes. Dans ce domaine, une grande partie de ce graphe est publiée en JSON-LD à l’intérieur des pages statiques, si bien qu’une base de données de graphe distincte est inutile.

Le domaine publié contient actuellement 11 128 objets JSON-LD typés portant 11 162 assertions de type et 1 849 identifiants uniques. Les relations derrière ces chiffres portent le sens. Un programme contient des instances de cours. Une instance de cours identifie un instructeur. Une page d’enseignants exprime la relation inverse, d’une personne vers les instances qu’elle enseigne ou soutient. Les vues programme et enseignants sont donc deux directions à travers un même graphe.

Figure — le graphe de connaissances

**Figure:** Le graphe de connaissances : 785 occurrences de cours par paramètre régional liées aux routes consolidées en 126 identités de cours indépendantes des routes ; des arêtes typées où une page programme porte CourseInstance.instructor et une page faculté exprime l’inverse via Person.@reverse.instructor ; et une limite à deux validateurs où un @id nu peut être une référence inter-documents valide tandis qu’un validateur de page unique ne peut inférer son type.

> **Figure caption:** Le graphe de connaissances : les occurrences de cours liées aux routes se réduisent à des invariants gouvernés, tandis que des liens instructor typés relient les vues programme et faculté.

La distinction entre un cours et une instance de cours est utile. [« Mathematics for Data Science »](https://dsti.school/fr/msc-data-science-ai#course-mathematics-for-data-science) peut constituer une seule identité de cours académique tout en apparaissant dans plusieurs programmes. Chaque occurrence dans un programme est une instance de cours, car elle appartient à un contexte éducatif particulier. Cette instance peut renvoyer au même cours gouverné et aux professeurs qui l’enseignent. Le modèle préserve à la fois l’identité et le contexte.

L’identité des cours a révélé la difficulté le plus clairement. Le domaine comptait autrefois 785 occurrences de cours liées à une route. Parce que leurs identifiants incluaient la route où elles apparaissaient, le même cours pouvait ressembler à plusieurs cours différents pour une machine. Une migration gouvernée a réconcilié ces occurrences en 126 identités de cours sémantiques, consignées au moyen de 197 entrées d’autorité. La migration a rendu l’identité des cours indépendante de la route.

Cela exigeait plus que la correspondance de chaînes. Deux libellés peuvent nommer le même cours même lorsque la ponctuation ou un ancien code de cours diffère. Deux cours peuvent porter des libellés semblables et rester académiquement distincts. La Direction des études peut délibérément attribuer des codes différents au fil de l’histoire des programmes. Certains anciens codes étaient dupliqués sur des cours nettement différents et ont dû être corrigés à la source. Une autorité de migration approuvée a résolu ces cas par le sens académique autant que par des indices de chaînes.

Les identifiants sont exprimés comme des identifiants web. Un [Internationalized Resource Identifier (IRI)](https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier) étend l’idée d’un [Uniform Resource Identifier (URI)](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) aux jeux de caractères internationaux et peut identifier une entité indépendamment du fait qu’elle soit ou non une page conventionnelle. En pratique, DSTI utilise des identifiants stables `https://dsti.school/...` avec des fragments pour les cours, les personnes et les instances. Chaque paramètre régional utilise un même `@id` de cours partagé pour le même cours académique, tandis que ses instances de cours locales conservent leur contexte de programme et de langue.

Ce point compte, car un localisateur et une identité ont des rôles distincts. `data-dsti-element-id` localise un élément de contenu gouverné dans la source maintenue. `data-dsti-source-id` consigne sa lignée depuis la source anglaise. Un `@id` JSON-LD identifie l’entité académique décrite par ce contenu. Garder ces rôles distincts préserve le sens des données.

Le même travail a introduit les [identités des enseignants](https://dsti.school/fr/enseignants) dans le [DSTI TechBlog](https://dsti.school/fr/techblog). Les signatures d’articles qui peuvent être réconciliées via l’autorité des enseignants réutilisent désormais les mêmes identifiants d’enseignants, remplaçant d’anciens fragments `Person` locaux à la page. Les contributeurs externes conservent des identités distinctes, car le graphe des enseignants gouverne les membres du corps enseignant de DSTI.

La relation professeur-cours exigeait une arête inverse valide dans le vocabulaire. Schema.org fournit `instructor` sur `CourseInstance` ; son vocabulaire n’a pas de propriété générale `Person.teaches`. La [syntaxe @reverse de JSON-LD](https://www.w3.org/TR/json-ld11/#reverse-properties) exprime l’inverse depuis la page des enseignants. Là, `@reverse.instructor` relie la `Person` aux instances de cours typées qu’elle enseigne ou soutient. Les vues directe et inverse concordent donc à travers une seule propriété Schema.org valide.

Le graphe rend compte de sa précision actuelle. Deux identifiants d’enseignants portent encore des variantes de nom d’affichage acceptées, et un petit ensemble de structures d’articles typées comme des cours a besoin d’un modèle sémantique plus propre. L’autorité rend ces arêtes suffisamment visibles pour qu’elles s’améliorent par les faits.

### Pourquoi deux validateurs peuvent diverger

Le [World Wide Web Consortium (W3C)](https://en.wikipedia.org/wiki/World_Wide_Web_Consortium) élabore une grande partie des normes sur lesquelles le Web est bâti. Schema.org fournit un vocabulaire largement utilisé pour les données structurées. Un validateur de données liées et un validateur mono-page orienté recherche peuvent néanmoins examiner des limites différentes.

Un validateur de données liées peut accepter un simple `@id` comme référence à un nœud défini ailleurs dans le graphe. Un validateur inspectant une page isolée peut ne voir qu’un objet non typé, car sa limite s’arrête à cette page. Le balisage public fournit désormais le type dont a besoin cette limite mono-page, tandis que le contrôle d’identité interne distingue une référence typée d’une définition en double.

La question de conception vient d’abord : le nœud est-il une nouvelle définition, une référence à une identité existante, ou une instance locale d’un cours partagé ? Une fois la limite établie, chaque validateur peut faire respecter la part qu’il est capable de voir ; un résultat vert confirme alors le modèle déjà choisi par l’autorité.

Le graphe suit donc le même schéma en trois parties que le reste du système. L’autorité consigne les identités et les équivalences approuvées. La limite distingue les entités, les occurrences et les éléments source. Les contrôles vérifient l’unicité, l’identité inter-langues, la symétrie professeur-cours et la validité Schema.org.

L’autorité fournit la conception. Chaque validateur en fait respecter les conséquences à une limite différente.

## 06 La machinerie doit s’effacer devant le rédacteur

Le dépôt est essentiel au système, tandis que la personne qui édite le contenu devrait vivre une opération de contenu claire. Cette séparation a façonné `manager2`.

Les rédacteurs, les publicateurs et les administrateurs de plateforme reçoivent un rôle et une surface de commandes gouvernée. Une primitive est une opération bornée aux entrées, préconditions, effets et preuves déclarés : préparer une version candidate, rafraîchir un annuaire, publier un média, prendre un instantané en production, le restaurer, ou déployer. La création de branche, l’assemblage de la version candidate, la pré-production et la publication demeurent présents comme des mécanismes derrière ces opérations, pris en charge par le package lui-même.

Figure — manager2 et les ports

**Figure:** manager2 : un plan de contrôle où 18 primitives de contenu-local s’exécutent dans une session locale tandis que 10 primitives d’automatisation-uniquement sont refusées à l’exécution locale de routine et routées vers la CI, l’approvisionnement rare n’étant disponible que via un bris de glace administrateur audité ; et une couche de données où le code opérationnel atteint un enregistrement d’agent ou l’annuaire des partenaires par un port, avec HubSpot comme pilote interchangeable du jour.

> **Figure caption:** manager2 : les opérations de contenu-local et d’automatisation-uniquement séparées dans le plan de contrôle ; les ports de domaine séparent la logique du domaine des fournisseurs de données du jour.

La surface de commandes contient 28 primitives gouvernées. Dix-huit sont disponibles pour le travail de contenu local ; dix s’exécutent exclusivement en automatisation. La distribution locale est refusée par défaut : une identité de pipeline attestée fournit le contexte d’exécution pour la promotion de routine, tandis qu’un rôle humain Single Sign-On (SSO) reste une session humaine, quels que soient ses privilèges. Le [Single sign-on](https://en.wikipedia.org/wiki/Single-sign-on) permet à une seule identité authentifiée d’atteindre plusieurs systèmes ; la vérification distincte du contexte d’exécution établit si l’appelant est l’automatisation de publication.

Le provisionnement rare du domaine dispose de sa propre route délibérément explicite. En tant qu’amorçage administratif occasionnel, il recourt à une opération de secours (« bris de glace ») d’administrateur de plateforme, auditée. La livraison de contenu de routine reste dans son pipeline, tandis que le provisionnement rare reste visiblement exceptionnel.

Le descripteur lisible par machine donne aux agents la même vue de la surface de commandes : arguments, préconditions, effets, contexte d’exécution et reçus. Il ressemble à la forme du [Model Context Protocol (MCP)](https://en.wikipedia.org/wiki/Model_Context_Protocol) utilisée pour décrire des outils aux clients de modèles de langue, car cette structure est efficace pour l’interaction avec les agents. Il reste un manifeste descriptif ; les commandes gouvernées conservent toute l’autorité d’exécution.

Cette séparation compte. Un test de dérive compare le manifeste descriptif au registre en production, garantissant que chaque nouvelle primitive est documentée et que chaque primitive retirée disparaît de la surface annoncée. Le schéma exige aussi que chaque primitive déclare si elle est `local-content` ou `automation-only`.

Le même découplage apparaît sous la surface de commandes. Une [Application Programming Interface (API)](https://en.wikipedia.org/wiki/Application_programming_interface) définit comment un logiciel demande à un autre système des données ou des actions. Il est tentant, pour le code opérationnel, de parler directement dans les champs d’un fournisseur : récupérer un objet HubSpot, lire ses propriétés, les afficher. C’est rapide, mais cela laisse le modèle de données du fournisseur devenir le modèle de l’école.

Le package utilise plutôt la logique du [patron de conception adaptateur](https://en.wikipedia.org/wiki/Adapter_pattern), souvent décrit ici comme ports et adaptateurs. Le domaine demande une fiche d’agent ou un annuaire de partenaires dans le langage métier de l’école. Cette demande est le port . HubSpot est le pilote (driver) ou adaptateur du moment placé derrière. Les tests peuvent remplacer le pilote par une source de fiches écrite à la main et afficher le même contenu partenaire indépendamment d’une connexion HubSpot en production.

Cela coûte plus de code que d’appeler directement le fournisseur. En échange, l’école définit ses données partenaires par le port, tandis que le fournisseur de stockage actuel reste un pilote remplaçable.

La même règle s’applique à la gestion du code source. [Amazon Web Services (AWS)](https://en.wikipedia.org/wiki/Amazon_Web_Services) CodeCommit fait autorité parce que l’organisation l’a choisi comme autorité Git actuelle. [GitHub](https://en.wikipedia.org/wiki/GitHub) en est la projection en lecture seule, pour la visibilité et la collaboration, préservant une seule autorité de déploiement. Il fournit aussi une surface de [suivi des tickets](https://en.wikipedia.org/wiki/Issue_tracking_system) par laquelle lecteurs et collaborateurs peuvent soumettre des rapports de bogues et des demandes de changement, en complément du rôle canonique de CodeCommit. Un futur changement de fournisseur exigerait un nouveau pilote et une nouvelle route opérationnelle, tandis que la définition d’une publication reste stable.

L’[instantané public figé du système](https://github.com/dsti-school/dsti-website-v377-public-snapshot) a une finalité distincte de cette projection maintenue. La projection appartient au processus de publication continu. L’instantané est une exposition archivée, délibérément inerte, d’un point de publication : son histoire figée et sa vocation d’éducation publique préservent le package continu comme seule autorité opérationnelle.

Le premier pipeline a échoué en transformant chaque preuve interne en cérémonie pour l’opérateur. Il collectait des reçus, des empreintes et des liaisons plus vite qu’un humain ne pouvait comprendre quelle décision chacun protégeait. Les mécanismes de sécurité avaient commencé à masquer le modèle opérationnel.

La correction a placé chaque preuve là où elle doit être. Un instantané consigne le domaine en production précédent. La préparation remplace la version candidate précédente et présente une seule tentative actuelle. La dernière préparation réussie est la version candidate éligible à la publication. Un déploiement réussi nettoie le matériel temporaire dont il est propriétaire et fait avancer les autorités Git. Un déploiement en échec restaure le prédécesseur capturé et laisse cet instantané disponible pour une restauration demandée par l’opérateur.

Un dépôt fait autorité. Le travail local porte uniquement sur le contenu. L’automatisation est propriétaire des écritures sur le domaine public. Git reste présent partout sous la surface, tandis que le rédacteur travaille au travers de l’opération de contenu.

Une bonne gouvernance se mesure aux défaillances importantes que le système peut prévenir pendant que l’opérateur reste concentré sur la décision à prendre.

## 07 La relecture doit valoir publication

La dernière promesse est la plus concrète : l’édition approuvée est l’édition publiée.

Pour comprendre le mécanisme, il est utile de décomposer l’ intégration continue et livraison continue (CI/CD) . L’[intégration continue](https://en.wikipedia.org/wiki/Continuous_integration) signifie que les changements sont intégrés et vérifiés au moyen d’un processus automatisé partagé, donnant à l’organisation des preuves au-delà de la machine d’un seul contributeur. La [livraison continue](https://en.wikipedia.org/wiki/Continuous_delivery) signifie qu’une version candidate validée peut cheminer par un parcours reproductible vers la publication. Ici, « continu » décrit la disponibilité et la reproductibilité ; la publication finale reste une décision humaine.

L’édition locale et la publication publique sont donc des cycles de vie distincts.

- Un rédacteur modifie la source maintenue sur une branche de contenu.

- La préparation gouvernée reconstruit l’ensemble du domaine et exécute ses contrôles de contenu, sémantiques et structurels.

- Le rédacteur relit l’ensemble des paramètres régionaux concernés, y compris les contrôles visuels choisis.

- La branche est poussée vers le dépôt canonique ( AWS CodeCommit ).

- AWS CodePipeline exécute sa pré-vérification hermétique dans AWS CodeBuild — en résolvant la chaîne d’outils et les packages gouvernés depuis AWS CodeArtifact —, reconstruit le domaine, puis exécute les tests dépendants de la version candidate et du navigateur avant de publier vers un domaine de pré-production privé.

- Le publicateur relit cette édition en pré-production et donne la seule approbation humaine de mise en ligne.

- Le pipeline de déploiement ( AWS CodePipeline ) répète les deux phases de test AWS CodeBuild autour de sa reconstruction et vérifie la version candidate approuvée avant de toucher au domaine public, puis fait avancer la publication canonique et sa projection GitHub en lecture seule.

Figure — le processus CI/CD

**Figure:** Le processus CI/CD : le travail de contenu uniquement local est poussé sur une branche de contenu ; la construction de pré-production exécute le ci-precheck hermétique, capture une base de référence en production strictement locale, prépare la version candidate, exécute les tests de candidate et de navigateur dans ci-postcheck, publie le domaine de relecture privé et enregistre son condensé ; l’approbation du publicateur est la seule décision humaine ; le pipeline de mise en ligne répète les deux phases de test autour de la préparation avant de vérifier le condensé en pré-production, staging-publish, le point de déploiement et le déploiement, puis fait avancer la publication canonique et la projection GitHub.

> **Figure caption:** Le processus CI/CD : le travail de contenu local devient une version candidate en pré-production ; l’approbation du publicateur lance un pipeline de mise en ligne sans interface, gardé par des vérifications de contenu en pré-production et de point de déploiement.

La pré-production est la limite de relecture. La version candidate y possède un condensé de contenu — une valeur calculée à partir de ses octets au moyen d’une [fonction de hachage cryptographique](https://en.wikipedia.org/wiki/Cryptographic_hash_function). Un bon hachage fait qu’un changement accidentel ou délibéré produit, de façon écrasante, un condensé différent. Comparer les condensés est donc un moyen compact d’établir que deux domaines assemblés contiennent le même contenu relu.

Le pipeline de mise en ligne établit de nouvelles preuves pour la construction antérieure. Il reconstruit sous l’exécutable gouverné, compare le condensé de la nouvelle version candidate à l’édition en pré-production, republie les octets relus vers la pré-production, vérifie le point de déploiement, capture la limite de restauration et n’applique qu’ensuite le domaine en production.

L’architecture statique aide. Le domaine public est un ensemble stable de fichiers versionnés conservés dans un [stockage objet](https://en.wikipedia.org/wiki/Object_storage) et distribués par un [réseau de diffusion de contenu (CDN)](https://en.wikipedia.org/wiki/Content_delivery_network) ; la relecture et la publication opèrent donc sur des versions candidates de fichiers immuables. Le déploiement peut capturer la version en production actuelle, appliquer le nouvel ensemble, et restaurer l’ensemble précédent si la transaction échoue.

La limite d’infrastructure accepte un téléversement réussi auprès du fournisseur. La preuve la plus forte se situe plus tôt, là où la version candidate assemblée est comparée à celle qui a été relue. Une relecture antérieure objet par objet ajoutait du poids opérationnel tout en apportant peu de sécurité supplémentaire ; la conception actuelle garde donc la preuve à la limite où elle est la plus forte.

### Une pré-production répétable dans une limite de concurrence explicite

La relecture est itérative, la pré-production doit donc être reproductible. Un rédacteur peut mettre en pré-production, découvrir un défaut, le corriger et remettre en pré-production au sein de la même version publique visée.

Cela crée une subtile situation de compétition. La branche de pré-production avance, mais une approbation plus ancienne peut rester visible assez longtemps pour être appliquée. Le déploiement actuel effectue une auto-vérification avant l’extraction et n’admet qu’une édition correspondant à l’état de pré-production courant. Une approbation périmée produit un message clair de remplacement, au lieu d’un échec Git de bas niveau.

La règle opérationnelle restante est étroite et explicite : approuver la mise en ligne après l’achèvement de la construction de pré-production courante. L’auto-vérification prévient l’échec connu de l’édition périmée, tandis que cette règle de séquencement couvre le court intervalle avant que l’état de pré-production se stabilise. C’est un bon exemple de langage d’ingénierie honnête : une réserve précise renforce une garantie en définissant sa véritable limite.

### L’environnement d’exécution fait partie de la version candidate

La reproductibilité dépend aussi des outils qui assemblent les fichiers. La même source devient reproductible lorsqu’elle est associée au même interpréteur, moteur de navigateur et générateur de contenu gouvernés.

L’exécutable opérateur [Python](https://en.wikipedia.org/wiki/Python_%28programming_language%29) est gouverné et verrouillé par hachage. Les contrôles de navigateur utilisent leur propre environnement Playwright. La validation HTML utilise un exécutable [Java](https://en.wikipedia.org/wiki/Java_%28programming_language%29) gouverné. ContentInventory utilise la chaîne d’outils .NET gouvernée. macOS, Linux et Windows partagent le parcours d’édition de contenu. La construction et le déploiement s’exécutent sur les environnements dans lesquels la chaîne d’outils complète a été acceptée ; Windows reste dans son périmètre d’édition de contenu éprouvé.

C’est une limite d’acceptation fondée sur les faits pour Windows. Il peut provisionner les outils média de niveau utilisateur dont il a besoin — [FFmpeg](https://en.wikipedia.org/wiki/FFmpeg), [ImageMagick](https://en.wikipedia.org/wiki/ImageMagick) et les outils [AV1 Image File Format (AVIF)](https://en.wikipedia.org/wiki/AVIF) via le gestionnaire de paquets Scoop — et exécuter les commandes d’édition prises en charge. Les environnements de construction et de publication restent ceux dans lesquels la chaîne d’outils complète a été éprouvée. Les faits guideront toute extension future de cette limite.

### Ce que révèle le nombre de tests

Le registre de tests contient 162 modules de test enregistrés, répartis selon le moment où leurs entrées requises existent. Un module regroupe des cas de test apparentés, de sorte que le nombre de modules et le nombre de tests diffèrent : la vérification complète exécute 1 292 cas de test dans la pré-vérification et 283 dans la post-vérification.

La première phase, `ci-precheck`, exécute 136 modules avant `prepare`. Ces tests sont hermétiques : des entrées contrôlées et des effets injectés les rendent indépendants d’un fournisseur en production, d’un navigateur ou d’un site déjà assemblé. Ils peuvent révéler un défaut avant que la construction coûteuse ne commence.

La seconde phase, `ci-postcheck`, exécute les 26 modules restants après que `prepare` a créé la version candidate de publication et provisionné l’exécutable de navigateur, avant toute écriture sur le domaine de pré-production ou de déploiement. Elle comprend des contrôles de construction, de traduction, d’acceptation et de navigateur dont l’entrée pertinente est la version candidate assemblée. La construction de pré-production comme la construction de mise en ligne exécutent les deux phases dans cet ordre.

Un contrat de complétude lisible par machine fait de la division une partition complète. Chaque module enregistré appartient à exactement une phase : les deux ensembles disjoints couvrent l’ensemble du registre. Avant ce contrat, 26 modules significatifs existaient dans des suites gouvernées en dehors des deux phases de CI.

Le nombre décrit la couverture ; le comportement que chaque test prouve détermine sa qualité. Mille tests faibles peuvent protéger moins qu’un seul test comportemental bien conçu. La question utile est celle de la défaillance que chaque famille est censée révéler. À travers les deux phases, le registre comprend, entre autres :

- les tests de gouvernance et de limite d’exécution, qui empêchent un contexte humain local d’usurper l’automatisation ;

- les tests d’isolation de construction, qui exigent que des constructions répétées produisent la même version candidate tant que la source maintenue reste inchangée ;

- les tests de modèle de contenu, qui protègent les sessions d’édition identifiées et les autorités générées ;

- les tests de paramètre régional et de traduction, qui comparent les familles de langue gouvernées et le domaine de publication préparé ;

- les tests sémantiques, qui réconcilient cours, professeurs et données structurées ;

- les tests de port de fournisseur, qui prouvent que le rendu du domaine reste indépendant d’un fournisseur en production ;

- les tests de documentation et de descripteur, qui comparent la surface de commandes annoncée à l’implémentation.

La division suit des limites techniques d’entrée. Chaque preuve significative s’exécute avant une écriture sur le domaine, dans la phase la plus précoce où ses entrées réelles existent. Un test périmé est corrigé, tandis qu’un test dont la finalité est révolue est retiré du registre.

Activer la surface complète a démontré pourquoi la distinction compte. Plusieurs tests dépendants de la version candidate lisaient la sortie construite depuis la source maintenue et n’exerçaient donc qu’un petit résidu — ou omettaient entièrement la preuve. Une fois que la CI les a réellement exécutés après la préparation, pointer les tests vers la version candidate a rétabli les preuves voulues et préservé le contenu valide. L’enregistrement disait qu’un test existait. L’exécution à la bonne limite a établi qu’il prouvait quelque chose.

C’est le moment où « ça marche sur ma machine » a cessé d’être pertinent. L’énoncé qui compte est devenu : la même opération gouvernée a produit la version candidate relue et la version candidate de publication, et le système a prouvé leur relation avant d’écrire le domaine.

## 08 Ce que l’organisation conserve

Le résultat visible de ce travail reste un site statique, et cette simplicité est une force. Un visiteur reçoit rapidement des pages ordinaires tandis que le système qui les a produites s’efface.

Le résultat important est que les décisions de l’école résident désormais dans des autorités partagées et durables.

Les variantes de langue sont consignées. La limite entre l’explication traduite et la substance académique canonique est consignée. L’identité d’un cours et sa relation à un professeur sont consignées. Les rôles autorisés à éditer, approuver et administrer sont consignés. La différence entre le travail local et l’automatisation de déploiement est consignée. Les conditions dans lesquelles la publication doit s’arrêter sont consignées.

Certaines de ces décisions sont du code. D’autres sont des fichiers d’autorité, des schémas, des tests ou des documents d’exploitation. Ce sont tous des livrables. Avec le logiciel fonctionnel, ils indiquent au prochain contributeur pourquoi ses limites existent.

C’est aussi pourquoi la documentation est plus qu’un commentaire autour du « vrai » package. Une commande périmée dans un guide d’exploitation peut provoquer l’échec d’une publication. Une description inexacte de la pré-production peut encourager une approbation pendant l’unique intervalle où elle n’est pas sûre. Un descripteur de primitive lisible par machine peut tromper un agent aussi efficacement qu’une fonction défaillante peut tromper un programme. La documentation doit être comparée à l’implémentation et, lorsque c’est possible, suffisamment structurée pour que des tests détectent la dérive.

Le chemin vers cette conclusion a comporté plusieurs corrections utiles. Des relectures de la documentation ont constaté que `staging-publish` avait été décrit comme la poussée de relecture jetable, un rôle qui appartenait à `staging-review`. Des relectures ultérieures ont précisé à quel moment le pointeur de pré-production était validé et ce qui se produisait après un échec Git. Le code avait souvent été correct ; c’est la prose qui devait se mettre à jour.

La correction durable a déplacé la description du cycle de vie dans des données structurées, contraintes par un schéma et vérifiées par rapport au registre des primitives en production et aux spécifications de construction de la CI. Un garde sémantique vérifie désormais que les primitives réservées à l’automatisation sont présentées par leur route d’automatisation. Les capacités de reprise indépendantes sont représentées comme des chemins indépendants, ce qui donne clairement à un agent leurs relations et leurs finalités prévues.

Cette histoire mérite d’être conservée car elle dit quelque chose de la dette technique. La dérive peut apparaître dans la prose actuelle aussi facilement que dans du vieux code, et une explication soignée peut porter une erreur avec assurance. La réponse pratique consiste à identifier les affirmations opérationnelles aux conséquences matérielles et à leur donner une autorité structurée là où cela réduit un risque réel, tandis que la prose continue d’en expliquer la finalité.

### Une vitrine publique à la finalité unique et immuable

Il restait un dernier test de ce raisonnement : le système lui-même pouvait-il devenir une vitrine publique sûre, transparente et réellement utile ?

La majeure partie du domaine visible était déjà publique au sens ordinaire. Un navigateur télécharge son HTML, son CSS, son JavaScript, ses données structurées et ses références média. Chacun peut inspecter les pages que le système livre. Publier le dépôt révèle une vue plus large : la source maintenue, les générateurs, les autorités, les tests et la conception de la mécanique de publication apparaissent ensemble. C’est le matériau nécessaire pour comprendre à la fois ce que contient le site et comment l’organisation cherche à le maintenir cohérent.

Une publication sûre exigeait une copie conçue à cet effet. Le package privé contenait aussi des liaisons de fournisseur en production, la topologie du domaine, les identités du dépôt et du pipeline, des routes de pré-production et une fonction de périphérie confidentielle gouvernée. La [limite d’instantané lisible par machine](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/PUBLIC_SNAPSHOT.json) consigne la finalité non opérationnelle qui en résulte et ses limites. La conception reste intelligible grâce à des espaces réservés typés et à des surfaces inertes, tandis que la carte opérationnelle demeure à l’intérieur de sa limite privée gouvernée.

Préserver la forme de l’infrastructure était essentiel à un compte rendu honnête des mécanismes que décrit cet article. La copie publique conserve donc l’architecture sous une forme inerte. Les identifiants de production deviennent des espaces réservés illustratifs typés. Les primitives tournées vers le fournisseur et les points d’entrée administratifs directs s’arrêtent à la limite de l’instantané public, avant tout accès à l’identité, aux identifiants ou au réseau. Les spécifications de construction incluses reconnaissent immédiatement le même marqueur, et les modèles d’infrastructure portent une condition de déploiement fausse et immuable.

La [fonction CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html) confidentielle a reçu une limite plus stricte. La préparation a laissé sa source d’origine non lue. Le chemin subsiste pour que l’architecture puisse toujours être suivie, tandis que son contenu est un [substitut inerte étiqueté](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/infrastructure/cloudfront/functions/training_password_request.js) renvoyant une réponse [Hypertext Transfer Protocol (HTTP)](https://en.wikipedia.org/wiki/HTTP) 503. L’instantané démontre la place architecturale de la fonction de périphérie tandis que son comportement reste confidentiel.

Le contenu public a suivi une règle de fidélité octet par octet. Le [manifeste de caviardage public](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/PUBLIC_REDACTION_MANIFEST.json) identifie les six racines de contenu et les consigne comme identiques octet pour octet à l’arbre source. Elles couvrent le site web maintenu, le domaine livré et les familles de supports awareness, facts, information et Sophia. Le même manifeste consigne que les 363 entrées de redirection conservées ne résolvent que vers des routes DSTI publiques, à l’écart des emplacements de pré-production, d’authentification et d’administration. Le classeur Dsti.ContentInventory a été inspecté en tant que conteneur de document et trouvé exempt de macros, de connexions externes, d’objets incorporés, d’adresses e-mail non publiées et de chemins de système de fichiers locaux.

Le résultat a ensuite été testé comme un objet à part entière, avec des preuves propres à la copie publique. Une suite d’instantané public bornée vérifie la limite d’exécution inerte, les schémas, la capture CloudFront caviardée, l’hygiène du système de fichiers et les contrats de construction et de contenu indépendants du fournisseur. Son [résultat de vérification consigné](https://github.com/dsti-school/dsti-website-v377-public-snapshot/blob/main/PUBLIC_REDACTION_MANIFEST.json) contient 108 tests réussis répartis sur 15 modules. Le générateur complet a également été exécuté dans une disposition de construction isolée et jetable ; 284 pages ont franchi le contrôle complet de cohérence du domaine et la construction s’est achevée indépendamment de tout accès au fournisseur. Un audit de résidu distinct a trouvé la copie publiable exempte de correspondances d’identifiants, de clés privées, de jetons et d’identifiants privés.

C’est alors seulement que la copie a reçu un historique Git : un nouveau commit racine sans parent contenant uniquement l’arbre public. Le [dépôt public](https://github.com/dsti-school/dsti-website-v377-public-snapshot) est archivé, garde ses workflows inactifs et conserve tous ses droits. Sa finalité est la transparence technique et l’éducation. Le package qui se poursuit demeure privé et canonique ; la vitrine reste figée à ce point de publication.

L’exercice a reproduit une dernière fois le motif directeur de l’article. La limite séparait le matériau nécessaire pour comprendre le système du matériau qui pouvait le reconnecter au domaine en production. L’ autorité était le commit source consigné, le manifeste de caviardage et l’arbre unique et immuable de l’instantané public. Le contrôle était la combinaison de vérifications d’équivalence de contenu, de tests de non-opérabilité, d’inspection de conteneur et de balayage de données sensibles qui devait réussir avant que le dépôt ne devienne public.

« Tout rendre public » a donc été analysé comme un ordre organisationnel : rendre l’ingénierie inspectable, préserver les preuves nécessaires pour en tirer des enseignements, et préserver une autorité opérationnelle claire.

### Là où le jugement humain intervient

La maintenance se poursuit.

Des lecteurs humains jugent le naturel au-delà des contrôles de traduction. Le graphe contient encore des identités qui peuvent être améliorées. Ce sont des personnes qui décident si la typographie est agréable, au-delà de l’automatisation du navigateur. Une réconciliation faculté-cours peut révéler que la Direction des études a utilisé le même code pour des cours différents ; l’autorité académique décide du nouveau code. La surface de test a un coût. La documentation peut dériver et doit être relue par rapport à l’implémentation.

La gouvernance contient des risques particuliers et rend visible l’incertitude qui subsiste.

Ce qu’elle change, c’est l’endroit où se situe l’incertitude. Un éditeur de contenu ordinaire peut compter sur le package pour porter le processus de publication. Un publicateur reçoit la preuve directe que la pré-production et la production contiennent la même version candidate. Un ingénieur futur peut inspecter les relations non résolues directement au niveau de leur autorité. L’organisation peut décider où le jugement humain est requis parce que les parties mécaniques en ont été séparées.

### Le tournant pédagogique

C’est pourquoi ce système a sa place dans la salle de classe.

ADIS enseigne aux étudiants à commencer par les activités, les événements, les données, les parties prenantes, les responsabilités et les contraintes, puis à choisir l’implémentation qui les sert. Le site web est désormais une étude de cas vivante de cette discipline. Et dans sa réalité de 2026 : assistée par LLM.

« Rencontrer les personnes dans leur propre langue » est devenu un modèle de paramètre régional, une limite de traduction et des contrôles inter-domaines. « Donner à l’organisation une mémoire partagée » est devenu un dépôt gouverné, des rôles et des surfaces d’exploitation explicites. « Le même professeur et le même cours doivent rester la même chose » est devenu une autorité d’identité et un graphe de connaissances. « Ce que nous approuvons est ce que nous publions » est devenu un condensé de pré-production, une décision du publicateur et un chemin de déploiement contrôlé.

Dans chaque cas, la technologie a suivi la promesse :

Promesse organisationnelle | Limite | Autorité | Contrôle

Rencontrer les lecteurs dans leur langue tout en préservant le programme | Explication localisable contre substance académique canonique | Autorités de paramètre régional et de terminologie | Cohérence de traduction, de route et de métadonnées

Laisser les éditeurs se concentrer sur le contenu tandis que l’automatisation gère le déploiement | Opérations de contenu locales contre écritures sur le domaine réservées à l’automatisation | Registre des primitives et modèle de contenu identifié | Vérifications de contexte d’exécution et de session d’édition

Conserver les personnes et les cours répétés comme une seule entité | Identité d’entité contre occurrence de page | Autorités d’identité de faculté et de cours | Vérifications d’unicité, de symétrie et Schema.org

Publier exactement ce qui a été relu | Édition locale, version candidate en pré-production et domaine en production | État Git canonique et condensé du contenu en pré-production | Vérifications de version candidate, de point de déploiement et de retour arrière

Rendre l’ingénierie inspectable dans une limite publique sûre | Explication publique du système contre liaisons du domaine en production | Commit racine public immuable et manifeste de caviardage | Vérifications d’équivalence de contenu, de fonctionnement inerte et de résidu sensible

Le tableau rend visible le fil directeur tandis que le système continue d’évoluer. Les limites gardent chaque promesse précise. Les autorités donnent aux décisions un foyer durable. Les contrôles transforment ces décisions en conditions que le système protège activement.

La partie 1 décrivait la reconstruction de trois semaines qui a rendu possible un domaine statique cohérent. La partie 2 traite de ce qui s’est produit lorsque ce domaine a dû devenir fiable sur le plan organisationnel. Le second problème était moins visible et, à bien des égards, plus difficile. Il a fallu construire des contrôles utiles et retirer le cérémonial ; ajouter des tests et corriger ceux qui avaient confondu l’expression locale avec une dérive factuelle ; publier des données structurées et décider de ce qu’étaient réellement les entités ; puis rendre la source visible au travers d’une vitrine publique dont le fonctionnement reste sûrement inerte.

Le site est devenu un système d’ingénierie lorsque les promesses de l’organisation ont acquis des limites, des autorités et des preuves — et lorsque le système a appris à énoncer la portée exacte de chaque preuve.

Le code est venu en dernier. Il devrait le rester.

---

© DSTI School of Engineering 2026 - Tous droits réservés. Établissement privé d’enseignement supérieur - V2026.378 - 1 septembre 2026