L'externalisation

Ce manuel est la référence interne de Sodimo. Certains de ses chapitres sont propres à Sodimo — l’ERP est Sodiwin, l’entrepôt est rue du Coin-de-Terre, le pipeline CRM comporte cinq étapes parce que c’est ainsi que Paul organise sa semaine. D’autres chapitres décrivent des schémas qui ne sont pas du tout spécifiques à Sodimo — le principe de la boîte noire, les trois principes de conception, le calendrier de rotation de clés, le coffre-fort. Ces schémas préexistent à Sodimo et lui survivront.

Jusqu’à présent, les deux types de contenu coexistaient dans le même manuel, et la seule façon de les distinguer était de les lire. Cela donnait l’impression que le manuel était plus lourd qu’il ne l’est — un lecteur chez Sodimo ne pouvait pas repérer rapidement quels chapitres étaient la recette propre à Sodimo et lesquels étaient un schéma emprunté. Et un lecteur extérieur à Sodimo (un futur engagement, ou quelqu’un qui a contribué à construire l’un des schémas à l’origine) n’avait aucun moyen d’extraire le contenu générique sans embarquer au passage une page sur la législation française de conservation des archives mail.

L’externalisation est le nettoyage. Chaque chapitre porte désormais un champ scope dans son frontmatter, et le manuel reste exactement tel quel pour un lecteur Sodimo — aucun chapitre n’est supprimé, aucun n’est déplacé. La coupe vit dans la publication, pas dans le contenu.

Le champ scope

Chaque chapitre sous src/content/manual/en/ porte désormais l’une des trois valeurs du champ scope dans son frontmatter :

• scope: sodimo — spécifique à l’engagement. Décrit Sodimo, son ERP, son équipe, son pipeline, son tableau de bord. Reste ici. Ne s’externalise pas.
• scope: leger — schéma réutilisable. Décrit une idée ou un flux de travail qui n’est pas propre à Sodimo — le contrat de données boîte noire, les trois principes de conception, le coffre-fort. S’externalise verbatim quand la seconde cible de rendu est câblée.
• scope: both — schéma partagé avec un chapitre spécifique à Sodimo. L’infrastructure, le harness, la stack mail, le guide de comptes. Reste ici, et une version générique s’en extrait en parallèle.

Les comptages à ce jour :

Quarante chapitres, un champ, trois valeurs. La classification a été faite chapitre par chapitre et est consignée dans l’annexe journal des décisions.

Pourquoi la coupe est nette

La coupe fonctionne parce que les trois familles d’artefacts ci-dessous sont déjà distinctes dans leur façon d’être rédigées et maintenues. Le champ scope ne fait que nommer une frontière qui existait déjà.

Modèles de référence. Les fichiers .container, les fichiers chezmoi .tmpl, les routes Caddy, les extraits de conf Postfix. Ce sont du code, pas de la documentation — le quadlet est la configuration. Les valeurs spécifiques au client sont substituées au moment de leger apply. Les modèles se décrivent eux-mêmes ; aucun chapitre ne les commente ligne par ligne. Ils vivent dans sodimo/dotfiles et sodimo/harness aujourd’hui et se séparent déjà proprement du manuel.

Runbooks. Procédures multi-systèmes ordonnées. Un opérateur s’authentifie sur plusieurs systèmes, câble la configuration entre eux, et vérifie le flux de bout en bout. La mise en place du tunnel Cloudflare, le basculement de migration mail, la vérification de premier démarrage de leger doctor. Les runbooks font référence aux modèles mais ne les incluent jamais en ligne. Ils sont écrits contre le schéma, pas contre Sodimo spécifiquement — l’opérateur substitue le nom du client à l’exécution.

Politiques-checklists. Attestations oui/non qu’un état requis existe ou qu’une action requise a été effectuée. Le compte Cloudflare du client a les quatre domaines migrés visibles et actifs. L’enveloppe papier du coffre-fort est dans le coffre. La rotation trimestrielle des clés a été réalisée dans sa fenêtre. Des vérifications d’état discrètes, pas des procédures ordonnées. Une politique-checklist fait référence à un runbook qui effectue le câblage ; la politique-checklist elle-même atteste seulement que le câblage est en place.

Un chapitre qui ressemble à des étapes ordonnées appartient à un runbook. Un chapitre qui ressemble à une attestation oui/non appartient à une politique-checklist. Un chapitre qui ressemble à une explication en prose d’un choix de conception appartient au manuel — et porte un champ scope indiquant au lecteur s’il est spécifique à Sodimo, un schéma réutilisable, ou les deux.

Ce que cela signifie pour ce manuel

Pour un lecteur Sodimo, rien ne change visiblement aujourd’hui. Le manuel se lit de la même façon. L’ordre des chapitres a légèrement évolué — le guide des comptes de référence a été promu au chapitre 36 et les chapitres OpenWebUI, coffre-fort et référence des quadlets ont chacun décalé d’un rang — mais le contenu est intact.

La variable d’environnement RENDER_TARGET est injectée dans chaque composant qui se branche sur le scope. Quand les scripts npm build:sodimo et build:leger frères seront en place (le dernier kilomètre, suivi séparément), le même arbre src/content/manual/ produira deux sites statiques : le manuel Sodimo complet, et une référence plus légère contenant uniquement les chapitres scope: leger et scope: both, avec les passages spécifiques à Sodimo extraits.

Ce que nous surveillons

Deux chapitres à revoir au fur et à mesure que l’extraction se précise :

• 38-vault est actuellement étiqueté scope: leger parce que le schéma de récupération par enveloppe papier est générique. Mais le texte du chapitre fait référence au coffre Sodimo spécifique, aux administrateurs nommés, et au libellé de consentement salarié CNIL. Avant que le rendu externe ne soit livré, soit le texte devient vraiment générique et reste scope: leger, soit l’étiquette passe à scope: both pour que le chapitre Sodimo reste verbatim ici pendant qu’une version allégée s’en extrait.
• 34-mail est étiqueté scope: both, ce qui est juste — Postfix / Dovecot / rspamd / Piler est un schéma générique. Mais le chapitre contient un bloc substantiel sur l’avis aux salariés CNIL et la politique de conservation de 10 ans des mails qui est un choix Sodimo, pas un schéma. L’extrait générique devra ce passage supprimé ou déplacé en annexe.

Aucun n’est bloquant. Les deux sont signalés dans l’annexe pour que le prochain éditeur sache où chercher.

État du pipeline

Cette page existe pour rendre l’état visible. L’externalisation est un cliquet — une fois un chapitre étiqueté, le seul changement possible est le déplacement de l’étiquette elle-même (par ex. leger → both si une spécificité Sodimo remonte), et le pipeline de publication rattrapant la classification déjà en place.