Cette expérience met à l’épreuve la conviction Le SDLC agentique est un sujet d'operating model.
Le symptôme trompeur
01 — Disparition
Ne pas restaurer. Reconstruire.
Le domaine existait encore. Le DNS répondait toujours. Mais le site, lui, n’était plus servi.
sebastienbourguignon.com avait été laissé sans hébergement actif depuis novembre 2024, alors que le nom de domaine restait enregistré et continuait de pointer vers l’infrastructure d’origine. Vu de l’extérieur, rien ne le signalait clairement : pas de page d’erreur explicite, pas d’avertissement visible avant d’essayer. Une requête sur le domaine renvoyait une réponse brute de l’hébergeur : « Site not installed - OVHcloud ». Le certificat présenté ne couvrait même plus le domaine demandé.
Ce symptôme est trompeur. Il ressemble à une panne applicative — un WordPress cassé, une base de données corrompue. Ce n’en était pas une. Il n’y avait tout simplement plus de site installé à cet endroit : l’hébergement n’était plus actif, pas le contenu perdu au sens strict. Le patrimoine — des années d’articles, de pages, de médias — existait quelque part, mais plus nulle part en ligne.
Face à ce constat, la tentation la plus simple aurait été de « réparer » : retrouver un hébergeur, réinstaller WordPress, restaurer une sauvegarde, et repartir à l’identique. Ça aurait été rapide. Ça aurait aussi reproduit, telle quelle, une architecture d’il y a dix ans, avec ses dépendances, ses fragilités potentielles et aucune preuve nouvelle de son bon fonctionnement.
Ce projet a pris le chemin inverse.
Ce qui peut être prouvé
02 — Recover
Reconstruire ne voulait pas dire reproduire à l’identique. Ça voulait dire partir de ce qui pouvait être prouvé.
La première étape n’a donc pas été le design ni l’architecture. Ça a été la récupération : rassembler, depuis plusieurs sources disponibles, tout ce qui pouvait être authentifié comme ayant réellement existé sur l’ancien site. Ce premier passage a permis de retrouver 2 325 contenus — 1 402 articles publiés via WordPress.com, 3 pages, et 920 éléments issus d’archives complémentaires.
Ce chiffre n’était qu’un point de départ, pas un résultat final — la suite de cette page explique pourquoi. Mais il fallait d’abord établir un socle fiable. 4 368 URLs historiques ont été identifiées et dédupliquées ; 1 624 fichiers médias uniques ont été récupérés et vérifiés un par un, chacun comparé à son empreinte d’origine pour garantir qu’aucune récupération n’introduisait de corruption silencieuse. Aucun échec d’intégrité n’a été toléré à cette étape.
Une règle a été posée dès ce moment, et n’a plus bougé depuis : ce corpus récupéré est immuable. Personne — ni humain, ni agent — ne le modifie après coup. Toute correction ultérieure se fait en aval, jamais en réécrivant la source d’origine. C’est une contrainte qui peut sembler rigide. Elle a évité, plus tard, qu’une erreur de traitement ne devienne indétectable.
Un système, pas un patchwork
03 — Rebuild
Récupérer le contenu ne suffisait pas. Il fallait aussi décider comment ce contenu allait exister à nouveau — pas seulement le remettre en ligne, mais lui donner un système capable de grandir sans se recasser à la moindre correction ponctuelle.
Le choix a été de séparer clairement deux préoccupations que l’ancien site mélangeait : la source du contenu, et sa transformation en pages publiques. Le corpus récupéré (le patrimoine) et le contenu produit aujourd’hui (les convictions, les publications, les expériences) sont lus par des composants dédiés, chacun responsable d’un seul type de document. Ces lectures alimentent un catalogue unique, qui devient la référence pour tout ce qui est publiable — un contenu qui n’y figure pas n’est jamais exposé, quelle qu’en soit la raison.
À partir de ce catalogue, un registre dédié attribue à chaque page une route, et une seule : aucune URL ne peut appartenir à deux contenus en même temps, aucun contenu ne peut se retrouver sans adresse. Le rendu final — les pages, les ressources statiques, l’index de recherche — est ensuite généré une fois, au moment de la construction du site, puis déployé tel quel.
Ce dernier point mérite d’être souligné : il y a très peu de code qui s’exécute réellement quand un visiteur charge une page. La quasi-totalité du travail — lire les sources, les valider, les assembler, vérifier qu’aucune règle n’est violée — se produit avant la mise en ligne, pas pendant. Aucune base de données n’est interrogée à la volée ; aucun service tiers ne porte de logique métier critique pour que le site fonctionne.
Peu de runtime, beaucoup de build-time.
Décider. Exécuter. Contrôler.
04 — Deliver
Ce site n’a pas été écrit ligne à ligne à la main, mais il n’a pas non plus été « généré » au sens où on l’entend parfois — un prompt, un résultat, terminé. Ce qui s’est réellement passé ressemble davantage à une chaîne de production : une intention posée par écrit, décomposée en décisions, transformée en spécifications précises, puis implémentée avec une assistance forte d’agents, avant d’être vérifiée, mesurée, et validée par un humain avant chaque mise en production.
Concrètement, chaque changement significatif suit le même chemin : une intention devient un brief, puis une architecture, puis un découpage en Epics et en Stories, chacune assortie d’une fiche de spécification qui fixe précisément ce qui doit être vrai une fois le travail terminé. L’implémentation elle-même a été fortement assistée par des agents — c’est ce que montrent le volume et la cohérence des artefacts produits (des dizaines de fiches de spécification, une chaîne de tests, une documentation de décisions).
Ce qui a réellement été mesuré, en revanche, c’est le calendrier : ce cycle de reconstruction a couru sur 11 jours calendaires et représente 104 commits, du premier corpus récupéré jusqu’à la clôture du dernier grand jalon de contrôle.
Chaque changement, avant d’être accepté, devait traverser une série de vérifications automatiques — contrats de contenu, tests, typage strict, build, audit indépendant, comparaison avec l’état précédent du site — puis une relecture humaine avant d’être intégré. Rien n’était mis en ligne uniquement parce qu’un agent l’avait produit.
C’est le constat qui a le plus marqué cette expérience : le code n’était pas le système. Le système, c’était l’ensemble des décisions, des contrats et des vérifications qui rendaient ce code digne de confiance.
Vitesse sans filet, jamais
05 — Control
Plus l’exécution est rapide, plus il devient tentant de sauter les vérifications — et plus, en réalité, elles deviennent nécessaires. Ce projet a fait le pari inverse de la vitesse sans filet : accepter une assistance forte à l’exécution, mais multiplier les points de contrôle qui garantissent que cette exécution reste maîtrisée.
Concrètement, aucun changement n’est intégré sans avoir traversé plusieurs vérifications distinctes : que chaque contrat de contenu — ce qu’un document a le droit ou non de contenir — est respecté ; qu’aucune route ne pointe vers deux contenus différents ; que les fichiers récupérés n’ont pas été altérés depuis leur intégration d’origine ; que le typage du code reste strict ; que le site se construit sans erreur ; qu’un audit indépendant, qui recalcule tout depuis les sources, retombe bien sur ce qui est réellement publié ; que le poids des pages et de l’index de recherche soit mesuré face à des budgets définis à l’avance, et que tout dépassement soit rendu visible puis arbitré explicitement plutôt que découvert en production ; et qu’un mécanisme de comparaison différentielle avec l’état précédent du site signale explicitement tout changement de comportement, pour qu’il soit accepté consciemment plutôt que découvert après coup.
Cette accumulation de contrôles n’est pas de la friction gratuite. C’est la condition qui a permis de garder confiance dans un rythme d’exécution qu’aucun humain seul n’aurait pu tenir.
8 gates de contrôle — 6 passés, 2 acceptés explicitement, aucun échec masqué.
- Ownership des routes / collisionsPASSAucune route ne pointe vers deux contenus différents (registre de routes unique).
- Contrats de domainePASSChaque contrat de contenu est vérifié avant intégration.
- TypeScript strictPASSAucune erreur de typage (tsc --noEmit).
- BuildPASSLe site se construit sans erreur.
- Audit indépendantPASSL'audit recalcule les routes émises depuis les sources et retombe sur l'état publié.
- BudgetsACCEPTÉIndex de recherche : dépassement mesuré (environ 15 %), arbitré explicitement.
- Baseline différentielleACCEPTÉ6 deltas acceptés, chacun avec une raison écrite.
- QA navigateurPASSCaptures desktop / mobile / no-JS / reduced-motion / 200% vérifiées.
Ce que ça prouve, pas ce qu’on affirme
06 — Evidence
Une expérience qui se contente d’affirmer n’en est pas une. Voici donc ce que ce projet peut réellement montrer, avec sa source.
Le premier chiffre à comprendre est double, et il faut le lire dans l’ordre. La première récupération, décrite en Acte 02, avait rassemblé 2 325 contenus depuis plusieurs sources hétérogènes — un premier socle, précieux mais partiel. Au fil du projet, une sauvegarde complète de l’ancienne base de données WordPress a été retrouvée et exploitée : une source plus complète et plus fiable que l’agrégation initiale. Elle est devenue la nouvelle source de vérité. Le corpus patrimonial final, celui qui alimente aujourd’hui le site, compte 3 246 articles.
2 325 et 3 246 ne mesurent donc pas la même chose : le premier est une première récupération multi-sources ; le second est le résultat d’un changement de source de vérité, survenu plus tard dans le projet. Ce n’est pas une croissance organique du même compteur — c’est un remplacement de méthode, documenté et assumé.
Autre preuve, de nature différente : au fil de la reconstruction, chaque évolution de comportement du site — un chiffre qui change, une page qui se déplace — a dû être explicitement acceptée avant d’être intégrée. Six de ces évolutions ont ainsi été validées consciemment, chacune avec sa raison écrite noir sur blanc, plutôt que silencieusement absorbées.
Le calendrier, déjà évoqué, reste une preuve à part entière de ce que cette reconstruction a représenté : 11 jours, 104 commits — peu, au regard de l’ampleur du corpus reconstruit et du nombre de vérifications traversées.
- Contenus historiques récupérés
- 2 325
recovery/reports/coverage-report.md
- Articles patrimoniaux
- 3 246
site/docs/baselines/brownfield.accepted.json#counts.articles
- Deltas acceptés avant cette expérience
- 6
_bmad-output/implementation-artifacts/epic-10-rebuild-evidence-dossier.md
Presque pas de runtime
07 — Infrastructure
Un point simple mérite d’être précisé, tant il tranche avec la complexité parfois perçue des projets qui manipulent de l’IA.
ce site n’a presque pas de runtime.
Pas de pipeline d’intégration continue hébergé à ce stade : une limite assumée, pas une omission cachée — et la prochaine étape naturelle d’industrialisation.
Ce qu’on retient
08 — Learn
Quatre choses, en particulier, ont changé la façon dont ce projet a été mené — pas des impressions vagues, mais des constats reliés à des faits précis.
Revue adversariale
une revue critique, volontairement exigeante, révèle des angles morts qu’une architecture jugée « propre » sur le papier ne montre jamais d’elle-même. Avant même de commencer à reconstruire, une revue adversariale dédiée a identifié sept écarts réels entre l’architecture prévue et l’état effectif du dépôt — tous corrigés avant de continuer. Sans cette étape, ces écarts auraient probablement été découverts bien plus tard, au pire moment.
Mesurer avant d’arbitrer
un budget fixé à l’avance, même soigneusement estimé, peut être dépassé une fois confronté à la mesure réelle. Le poids de l’index de recherche du site, budgété avant construction, l’a dépassé d’environ 15 % une fois réellement mesuré. La réponse n’a pas été de masquer l’écart, mais de l’arbitrer explicitement, en connaissance de cause.
Savoir renoncer
renoncer honnêtement à un périmètre peut valoir mieux que le livrer de force. Un chantier entier du projet — une visionneuse dédiée à des centaines de documents de présentation — n’a produit aucune Story terminée. Plutôt que de forcer une version dégradée, la décision a été de l’assumer comme non livrée : un résultat documenté, pas caché.
Concevoir par invariants
poser des invariants dans l’architecture, avant même de savoir exactement à quoi ils serviront, peut préparer des usages qui n’existent pas encore. Le type de document que représente cette page — une « expérience » — avait été réservé dans le système de catalogue dès les tout premiers jours du projet, sans qu’aucun contenu ne l’utilise encore. Cette page, aujourd’hui, en est la première mise en œuvre concrète.
Ce qui résiste
09 — Limits
Cette expérience n’a rien d’un succès sans accroc, et il serait malhonnête de le laisser croire.
Un chantier non livré
un chantier n’a pas été livré du tout. La visionneuse de présentations prévue dans le projet n’a donné lieu à aucune Story terminée : plusieurs centaines de documents restent aujourd’hui sans page dédiée. Ce n’est pas un détail — c’est un périmètre entier resté à l’état d’intention.
Un budget dépassé
un budget technique a été dépassé, et pas de justesse : l’index de recherche du site pèse environ 15 % de plus que ce qui avait été fixé comme limite. Le dépassement a été mesuré, accepté et documenté, mais il reste un dépassement, pas une réussite déguisée.
Sept écarts d’architecture
l’architecture initialement prévue pour ce projet contenait sept écarts réels avec l’état effectif du dépôt — des incohérences qui, si elles n’avaient pas été détectées avant de commencer à construire, auraient probablement coûté beaucoup plus cher à corriger en cours de route. Qu’elles aient été trouvées et corrigées est positif ; qu’elles aient existé au départ ne l’est pas.
Accessibilité automatisée partielle
la couverture d’accessibilité automatisée reste partielle. Les gates vérifient plusieurs invariants DOM ciblés, mais aucun audit outillé complet de type axe-core n’est aujourd’hui intégré. Une partie de la validation reste donc dépendante de la recette humaine et perceptuelle. Ces limites ne sont pas résolues par cette page. Elles sont écrites ici pour rester visibles.
10 — Next
Cette page documente une reconstruction achevée, mais elle n’est pas une fin en soi.
Le Rebuild n’est pas seulement l’objet de cette page. Il est aussi l’infrastructure qui permettra de documenter les expériences suivantes.
Le système construit ici — le catalogue, les contrats, les contrôles, la manière de transformer une intention en preuve vérifiable — n’est pas spécifique à ce seul sujet. Il a été pensé pour accueillir d’autres expériences, le jour où elles existeront réellement, avec leurs propres preuves. Rien n’est annoncé ici qui ne soit pas déjà construit.