# Reconstruire dsti.school : dix-huit mois sur le terrain, trois semaines au clavier HTML canonique: https://dsti.school/fr/techblog/refonte-dsti-school-printemps-2026 Cette version Markdown est générée par le même build du site statique DSTI que la page HTML canonique. Elle est destinée à la lisibilité machine et à une consultation concise. [DSTI TechBlog](https://dsti.school/fr/techblog)  /  Team DSTI Team DSTI Systèmes · institutions · mise en production Une analyse technique complète de la refonte intégrale d’un site web — et des raisons concrètes pour lesquelles une petite école sélective, pensée pour le monde, avait besoin de chacune de ses composantes. ![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 22 juin 2026 43 min de lecture mis à jour jusqu’à V308 site-statique aws-cloudfront contrôles-ci schema.org llms.txt css-par-page xml-xsd ia-portable L’ingénierie vue de l’intérieur de DSTI ## De la réalité organisationnelle à une version capable de faire ses preuves 01 Observer Dix-huit mois de conversations, de voyages et d’enseignements tirés du recrutement international. 02 Modéliser Traduire les besoins, les contraintes, les acteurs et les risques en un système d’information explicite. 03 Construire Transformer le modèle en sources, outils, contenus et diffusion en périphérie déterministes. 04 Démontrer Refuser la publication tant que chaque contrôle bloquant n’est pas validé. 18 mois apprentissage sur le terrain 3 sem. reconstruction intégrale V308 version décrite ici Voici la version longue de la refonte de [dsti.school](https://dsti.school/) — et la raison pour laquelle une petite école d’ingénieurs sélective établie sur la [Côte d’Azur](https://dsti.school/fr/vie-cote-azur) a fini par écrire sa propre chaîne de build de site statique, son propre validateur schema.org et son propre moteur de géolocalisation à la périphérie du réseau. La version courte tient en une phrase : l’essentiel de ce qui ressemble à du marketing relève en réalité de l’ingénierie, et l’essentiel de cette ingénierie ne prend tout son sens qu’une fois que l’on sait à quoi elle sert . Cet article présente donc les deux : les systèmes, dans leur intégralité, et les raisons qui les sous-tendent. Deux efforts progressent en parallèle tout au long de cette histoire. Le premier correspond à dix-huit mois de développement d’un réseau mondial de partenaires, sur le terrain, institution après institution. Le second tient en trois semaines de reconstruction complète du site web. Ils semblent sans rapport. Ils relèvent pourtant du même projet : un effort continu pour gagner la confiance d’une famille envers une école dont elle n’a souvent jamais entendu parler, dans un pays qui lui vient rarement spontanément à l’esprit. Le site web poursuit cet effort pendant que tout le monde dort ; il se doit donc d’être à la hauteur. Le regard pédagogique derrière le build ## Analyser avant d’implémenter Il s’agit d’un récit Team DSTI, mais il reflète aussi la discipline des systèmes d’information enseignée au sein de l’école : comprendre l’organisation avant de décider ce qu’il faut construire. L’analyse formalise le « quoi » d’un système ; la conception transforme ce « quoi » en un « comment » cohérent. Sébastien enseigne actuellement Analysis & Design of Information Systems dans le [MSc in Data Analytics with AI](https://dsti.school/fr/msc-data-analytics-ai) et le [MSc in Data Engineering for AI](https://dsti.school/fr/msc-data-engineering-ai). Son principe pratique s’applique directement ici : les projets échouent souvent non parce que personne ne sait coder, mais parce que les activités, les données, les parties prenantes, les événements, les contraintes et les responsabilités n’ont pas été compris avec suffisamment de précision avant le début de l’implémentation. [MSc Data Analytics with AI](https://dsti.school/fr/msc-data-analytics-ai) [MSc Data Engineering for AI](https://dsti.school/fr/msc-data-engineering-ai) [Executive MSc](https://dsti.school/fr/executive-msc-intelligence-artificielle-transformation-digitale) [BSc Computer Science & Engineering](https://dsti.school/fr/bsc-informatique-ingenierie) [AI Awareness](https://awareness.dsti.school/) Fondations des systèmes Création et enseignement de Computer Architecture, Networking, Data Management et AI Awareness dans le DSTI Warm Up ; de Data Wrangling with SQL, également dans l’Executive MSc ; ainsi que de Software Engineering Parts 1 & 2 dans les MSc consacrés aux données. Données d’entreprise et collaboration Création et enseignement de CRM Data Management auprès des publics des MSc Data Engineering, MSc Data Analytics et Executive MSc, ainsi que de Relational Database Management Systems et Systems and Applications for Enterprise Collaboration dans le BSc. Architecture, du matériel au cloud Création et enseignement de Computer Architecture and Operating Systems et Introduction to Computer Networks dans le BSc ; enseignement également du programme officiel AWS Solution Architect dans les programmes DSTI en qualité d’instructeur Amazon AWS certifié. ## 01 Pourquoi il existe : un réseau, pas un marché national Avant la moindre ligne de code : le site web a été reconstruit en raison de l’origine réelle de nos étudiants. Au cours des dix-huit derniers mois, le réseau de partenaires conseillers en études à l’étranger de DSTI est passé de quelques dizaines de relations à 92 partenaires agréés dans 78 pays et territoires . Cette croissance s’est faite en personne — salons, visites de campus, longues conversations — et elle a transformé le rôle que doit jouer le site. Ce n’est plus une brochure destinée à des personnes qui nous connaissent déjà. Il devient de plus en plus souvent la première rencontre sérieuse d’un futur étudiant à Lagos, La Paz, Hanoï ou Bogotá avec l’école, sur un téléphone, avec une connexion instable, dans une langue qui n’est peut-être pas la sienne. Ce seul constat détermine presque toutes les contraintes techniques qui suivent : le site doit être rapide sur mobile , lisible par les machines autant que par les personnes , disponible en plusieurs langues, chacune traitée comme une langue de premier rang , et impossible à publier s’il est défectueux , car il est rare que quelqu’un soit éveillé pour s’en apercevoir. Aucun de ces choix n’est esthétique. Ils découlent de la personne qui se trouve à l’autre bout. ## 02 Le pari : le savoir-faire pour rivaliser à armes égales Nous sommes une petite structure. Nous n’avons ni un nom célèbre ni un budget immense, et nous n’allons acquérir ni l’un ni l’autre ce trimestre. Ce qu’une petite équipe peut maîtriser, c’est la qualité de ce qu’elle met réellement en ligne. Le pari de cette refonte était donc volontairement classique : résoudre le problème par une meilleure ingénierie. Rendre le site plus rapide, plus propre, plus fiable et plus lisible par les machines que ceux d’écoles cent fois plus grandes, car cette compétition se gagne par le soin et la discipline, non par le niveau de dépense. C’est aussi pourquoi la refonte a créé une dynamique cumulative plutôt qu’un simple changement de design. Chaque propriété de qualité recherchée — vitesse, validité, lisibilité machine — a été transformée en quelque chose que le build peut vérifier à chaque version , afin que l’exigence soit maintenue sans dépendre de la mémoire de chacun. Figure — la dynamique cumulative de la qualité **Figure:** Une dynamique cumulative : savoir-faire et vitesse améliorent la visibilité, attirent les bons candidats, renforcent la réputation et permettent de réinvestir dans davantage de qualité > **Figure caption:** Aucun gain n’est décisif à lui seul ; ensemble, ils se renforcent et entretiennent le mouvement. Cette accumulation constitue toute la stratégie — et c’est exactement ce qu’alimente le réseau du chapitre 1. ## 03 La vitesse, parce que les millisecondes comptent dans le recrutement Un futur étudiant confronté à une connexion irrégulière en altitude n’attend pas qu’une page lente se charge : il part. Nous avons donc mesuré nos performances sur mobile, là où cela compte réellement, par rapport aux écoles d’ingénieurs les plus célèbres au monde — non pour prétendre mieux enseigner, mais pour situer un ordre de grandeur technique. Figure — la course à la vitesse sur mobile (Lighthouse, 19 juin 2026) **Figure:** Scores de performance mobile : DSTI arrive en tête avec 96, devant Edinburgh 75, Imperial 70, Stanford 68, Cambridge 63, CentraleSupélec 58, MIT 57, Harvard 55, Polytechnique 50 et ETH Zürich 39 > **Figure caption:** Mesures de laboratoire, et non classement permanent : les pages, réseaux, outils de consentement et caches diffèrent, et cela ne dit rien de la qualité de ces excellentes institutions. La figure situe un ordre de grandeur technique : sur téléphone, notre page d’accueil est la plus rapide du groupe. Une capture rapide peut relever de la chance ; un site durablement rapide relève de l’ingénierie. Les trois mesures réellement utilisées par les Core Web Vitals de Google — la vitesse d’apparition du contenu principal, la rapidité de réaction de la page à une interaction et l’ampleur de ses déplacements visuels pendant le chargement — se situent toutes dans la zone « bonne », et le build maintient ce niveau à chaque version. Du HTML prégénéré dans S3 derrière un CDN signifie qu’aucun rendu n’est effectué à chaque requête ; s’y ajoutent des images AVIF, des indications de préchargement ciblées, un chemin critique volontairement léger et une optimisation qui mérite d’être détaillée parce qu’elle paraît anodine alors qu’elle ne l’est pas. ### La suite de V308 : supprimer le travail évitable avant de modifier l’architecture La première version suivant la refonte présentait encore un avertissement intermittent de Lighthouse dans notre propre runtime : un gestionnaire de défilement pouvait mettre à jour la barre de progression de lecture puis demander au navigateur une nouvelle géométrie des sections au cours du même cycle. V308 a réorganisé ce chemin autour d’un unique `requestAnimationFrame` : la hauteur de l’en-tête sticky et les positions des sections sont mises en cache, la géométrie n’est lue qu’une fois, puis les classes de progression ou d’état actif sont écrites. La même version a déplacé les feuilles de style référencées avant les blocs JSON-LD volumineux dans les pages maintenues, les pages générées et les chaînes de build des supports, tout en préservant l’ordre des feuilles de style. C’était délibérément l’option prudente : aucune séparation du CSS critique, aucune astuce de chargement asynchrone des feuilles de style et aucune nouvelle cascade à démontrer. Le premier test mobile en laboratoire après déploiement a reflété ce changement sans prétendre qu’une seule exécution constitue une donnée de terrain : First Contentful Paint est resté à 0,9 s ; Largest Contentful Paint est passé de 2,9 s à 2,7 s ; Total Blocking Time a chuté de 190 ms à 30 ms ; Speed Index est passé de 1,1 s à 0,9 s ; et Cumulative Layout Shift est resté à 0 . Le chemin critique maximal mesuré a été réduit de 159 ms à 98 ms . Lighthouse signale encore, à juste titre, une ressource bloquant le rendu — la feuille de style élaguée de 19,5 KiB de la page — car nous avons privilégié un premier rendu prévisible plutôt que la suppression d’un avertissement à tout prix. ### Une feuille de style par page — et pourquoi c’est difficile La méthode habituelle consiste à construire un site avec une grande feuille de style partagée, ce qui oblige chaque page à télécharger, analyser et appliquer des milliers de règles qu’elle n’utilisera jamais. Nous faisons l’inverse : chaque page livre une feuille de style réduite aux règles dont elle a réellement besoin. Moins de données à transmettre, moins de travail à effectuer par le navigateur avant l’affichage. Le problème est qu’il est impossible d’élaguer uniquement à partir de ce qui figure dans le HTML de la page. La version naïve — « supprimer toute règle dont le sélecteur n’apparaît jamais dans cette page » — casse discrètement le site, car les classes les plus importantes ne figurent pas du tout dans le HTML enregistré. JavaScript les ajoute à l’exécution : un menu devient `open` lorsqu’on le touche, un en-tête devient `sticky` et `scrolled` pendant le défilement, une boîte de dialogue devient `active`, la bannière de cookies bascule sur `consent`, un élément devient `selected` ou `loading`. Supprimer ces règles « inutilisées » ferait perdre son style à chaque interaction. L’optimiseur conserve donc une liste d’autorisation volontairement prudente de ces marqueurs d’état dynamique et ne les supprime jamais. Trois autres éléments compliquent encore l’exercice : les sélecteurs ne se lisent pas de gauche à droite (`:is()`, `:where()` et `:has()` imbriquent d’autres sélecteurs, ce qui exige une correspondance récursive) ; les règles précédées de @ se divisent en deux catégories (`@media`/`@container` encapsulent des règles qu’il faut parcourir, tandis que `@font-face`/`@keyframes` sont référencées par leur nom et conservées comme des blocs opaques) ; enfin, certains CSS modernes réellement utilisés — les requêtes de conteneur avec `container-type` et les unités `cqi` — sont suffisamment récents pour que le validateur HTML/CSS les signale encore comme utilisant une propriété « inexistante ». Le pipeline les conserve donc comme faux positifs connus et examinés. La suppression de CSS étant risquée, chaque page élaguée est ensuite comparée à l’original par un vérificateur distinct avant toute publication. ## 04 Portée : trois langues à part entière Le site est né bilingue — anglais et français. L’espagnol (`es-MX`) est l’ajout le plus récent, et il est utile d’en expliquer la logique puisqu’il s’agit d’une décision d’entreprise, non d’un simple exercice de traduction. L’espagnol est la seule langue qui donne accès à tout un continent : une seule version linguistique ouvre d’un coup l’Amérique latine, à l’exception du Brésil, tandis que chacune des nombreuses langues d’Asie n’en ouvrirait qu’une partie. L’espagnol a donc toute sa place non parce qu’il serait abstraitement la « deuxième langue des affaires », mais en raison de la portée exceptionnelle qu’offre une seule version linguistique. Figure — une source, trois langues à part entière **Figure:** Trois langues, en-GB, fr et es-MX, reliées par des hreflang réciproques et disposant chacune de jumeaux lisibles par machine > **Figure caption:** Chaque langue constitue une véritable destination avec des liens hreflang réciproques afin que les moteurs de recherche servent la bonne version ; les URLs ne sont jamais traduites automatiquement. Le chapitre suivant revient sur les jumeaux lisibles par machine. Surtout, les langues ne sont pas organisées comme un site principal auquel on aurait greffé des traductions. Chacune est une destination à part entière produite à partir d’une source unique, avec une réciprocité `hreflang` correcte, un `x-default` et une liste stricte des éléments à ne pas traduire : noms de programmes, marques, noms des certificateurs et des campus, ainsi que noms des modes d’études — tout ce qui doit rester identique dans chaque langue pour rester facile à trouver et correct. ### La gouvernance de la traduction est devenue une mémoire du build La traduction française du long récit Team DSTI a mis en évidence une distinction importante : un bon référentiel de traduction a besoin à la fois de règles normatives et des éléments qui ont conduit à les établir. À partir de V308, la passation comportait donc une autorité de traduction maintenue, ainsi que des fichiers de provenance distincts pour le français et l’espagnol mexicain. L’autorité précise ce qui doit être préservé — identifiants, URLs, noms officiels des programmes et des modes d’études, attribution de la première personne, balisage et sens lisible par machine. Les fichiers de provenance consignent la manière dont s’exprime naturellement un contenu destiné au public dans chaque langue : français international neutre avec vous ; espagnol mexicain professionnel avec tú ; conventions numériques distinctes ; terminologie récurrente ; contrôles des faux amis et des variantes propres à l’Espagne. Ces fichiers ne sont pas de simples notes. Ils font obligatoirement partie du paquet sélectionné pour le modèle suivant, dans son ordre de lecture, ses sommes de contrôle, ses manifestes et son rapport de structure. Un futur traducteur — humain ou modèle — reçoit ainsi non seulement la règle, mais aussi sa provenance et le vocabulaire de QA nécessaire pour tester le résultat. La localisation devient une autre surface d’ingénierie reproductible, au lieu de rester une mémoire détenue par la dernière personne ayant traduit une page. ## 05 Lisible par les personnes et par les machines Pour la première fois dans l’histoire du web, deux catégories de lecteurs comptent : les personnes et les systèmes d’IA qui répondent de plus en plus à leurs questions. Une école qui souhaite être découverte doit désormais être lisible par les deux ; chaque page contient donc davantage que ce que l’on voit. Figure — une page, quatre représentations, deux publics **Figure:** Une page se décline en HTML, JSON-LD, jumeau Markdown et llms.txt pour alimenter les moteurs de recherche et les assistants IA > **Figure caption:** Le HTML visible est destiné aux personnes et aux robots d’exploration ; le JSON-LD indique précisément aux machines ce qu’ est un programme, un tarif ou une date ; le jumeau Markdown et llms.txt fournissent aux systèmes d’IA une copie claire et sans ambiguïté. Nous ne devinons pas comment être cités : nous l’exposons explicitement. Le HTML visible est destiné aux personnes et aux robots d’exploration ; schema.org JSON-LD indique précisément aux machines ce qu’ est un programme, un tarif ou une date ; un jumeau Markdown fidèle de chaque page et un index llms.txt fournissent aux systèmes d’IA une copie claire et sans ambiguïté. Lorsqu’un futur étudiant demande à un assistant « où étudier le data engineering en France, en anglais ? », les systèmes qui répondent lisent des données structurées et un texte propre, au lieu de tenter de déchiffrer une jolie page. La plupart des institutions n’ont pas publié de version d’elles-mêmes lisible par machine. Nous l’avons fait. ### Le contrôle schema.org nous appartient et ne triche pas Deux précisions méritent d’être apportées. Premièrement, ce validateur schema.org est développé en interne . Le vocabulaire est public et il existe un vérificateur interactif sur le web, mais aucun outil exécutable sans intervention dans un build, comme c’est le cas pour le validateur HTML. Nous avons donc écrit un vérificateur dédié qui récupère le vocabulaire officiel schema.org et reproduit, page par page et sans intervention humaine, ce qu’afficherait le Schema Markup Validator en ligne. Deuxièmement, et surtout, nous n’avons jamais recherché un résultat flatteur de type « zéro erreur, zéro avertissement » en supprimant du balisage. schema.org est volontairement un vocabulaire ouvert : une propriété qu’il ne déclare pas formellement constitue un avertissement , non une erreur. La solution facile consiste à supprimer les champs concernés, ce qui fait disparaître du sens. À l’inverse, les erreurs bloquent immédiatement la version, tandis que les avertissements sont examinés et conservés lorsque le balisage est réellement juste et utile. Nous validons la structure sans l’amputer. Un premier signe extérieur que le pari commence à porter ses fruits. Pendant que nous terminions ce travail, Lighthouse de Google — le moteur qui sous-tend PageSpeed Insights — a discrètement ajouté une catégorie expérimentale « Agentic browsing » qui évalue la préparation d’une page pour les agents d’IA plutôt que pour les personnes. Trois de ses contrôles par défaut portent sur un arbre d’accessibilité bien formé, l’absence de déplacement de mise en page et la présence d’un `llms.txt` valide. La page d’accueil de DSTI réussit les trois : un résultat net de 3/3 . Google précise encore ne pas utiliser `llms.txt` pour Search, et la catégorie est ouvertement « en cours de développement » ; il ne s’agit donc pas d’un trophée de classement, mais du signe le plus clair à ce jour que les plateformes évoluent dans la direction de contenus pensés pour les lecteurs machine avant même que cela ne devienne obligatoire. Nous n’avions pas anticipé cet audit. Nous le réussissions simplement déjà. ## 06 Conçu pour ne pas casser Un site statique n’est pas fragile ; correctement conçu, c’est même l’inverse. L’ensemble du site est constitué de HTML prérendu dans un stockage objet, verrouillé pour n’être servi qu’à travers le CDN, avec un pare-feu applicatif web, une protection DDoS gérée en périphérie et le DNS en amont. Aucun serveur d’application ne peut tomber à 2 heures du matin, puisqu’il n’existe aucun serveur d’application. Figure — l’ancien chemin de requête et le nouveau **Figure:** L’ancien chemin WordPress assemble une page à chaque requête à partir de PHP, d’une base de données et d’extensions ; le nouveau sert un fichier préconstruit depuis un CDN derrière un pare-feu > **Figure caption:** En haut, la défaillance d’un seul composant fait échouer la page. En bas, la page est déjà construite : le visiteur la reçoit simplement, à travers un pare-feu, depuis un réseau conçu pour rester disponible. La seule migration réellement délicate concernait le comportement des URLs. L’ancienne configuration reposait sur la logique `try_files` d’un serveur web pour associer des URLs propres, sans extension, à des fichiers ; la nouvelle périphérie devait reproduire ce comportement avec une petite fonction CDN et gérer la particularité selon laquelle une origine verrouillée renvoie, pour un objet absent, un statut différent de celui auquel on s’attend. Mettre cette logique de réécriture exactement au point — afin que chaque ancien lien fonctionne et qu’aucune erreur 404 ne survienne par accident — a constitué l’essentiel du travail véritablement minutieux de ces trois semaines, avec la création d’une table de redirections entre les sitemaps de l’ancien site et la nouvelle structure. ## 07 Une validité démontrable : neuf contrôles et le refus de publier Voici la partie qui surprend le plus. Le système refuse de publier une version qui échoue à ses propres contrôles. Il ne s’agit pas d’une consigne du type « soyez prudent au moment du déploiement », mais d’une machine qui empêche toute page défectueuse ou non validée d’être mise en ligne. Au cœur du dispositif, la publication est une machine à états finis. Figure — la publication comme machine à états finis **Figure:** États : édition, candidat, préparation, contrôles de validation, prêt et publié, avec une boucle d’échec vers un candidat conservé et une transition de retour arrière > **Figure caption:** Rien de partiel n’est jamais publié : un échec renvoie le système vers un candidat conservé, et une version peut revenir à une version antérieure identifiée. Déterministe et réentrant. Rien de partiel n’est jamais publié : l’échec d’une étape de contrôle renvoie le système vers un candidat conservé, et une version peut être rétablie à partir d’une version antérieure identifiée. Les étapes bloquantes sont, dans l’ordre : build (esbuild analyse et minifie chaque fichier externe `.js` et `.css`, tandis que le minifieur HTML fonctionne avec la minification du JavaScript inline expressément désactivée , afin qu’aucun script ne soit réécrit) → VNU HTML et CSS (la sortie doit être vide) → validité du JavaScript inline (chaque `