Portfolio BTS SIO SISR : site statique et binôme avec une IA

Objectifs

• Relier chaque compétence du référentiel BTS SIO à ses réalisations et à ses preuves, dans les deux sens.
• Ajouter une réalisation, une preuve ou un article de veille en déposant un seul fichier Markdown.
• Rendre visible tout champ non renseigné plutôt que de le masquer ou de l'inventer.
• Garantir un site intégralement lisible sans JavaScript et sans requête vers un domaine tiers.
• Disposer d'une URL directe par réalisation, ouvrable pendant une soutenance.

Architecture

Le contenu est séparé de l'interface. Les réalisations et les articles de veille sont des fichiers Markdown validés au build par un schéma Zod : un champ inconnu ou une valeur hors liste arrête la génération avec un message explicite. Une couche de requêtes unique, src/data/collections.ts, porte tout le lien compétence ↔ réalisation ↔ preuve ; les composants ne connaissent que ses fonctions. Déposer un fichier Markdown génère donc la page de la réalisation, sa fiche E6 le cas échéant, son entrée dans la bibliothèque filtrable, les filtres correspondants, les lignes des tableaux croisés E5, E6 et E7, les liens depuis chaque compétence rattachée et les entrées du registre documentaire. Le rendu est entièrement statique : dist/ se dépose sur n'importe quel hébergeur de fichiers.

Étapes de réalisation

Configurations

• Schémas de contenu : listes fermées plutôt que texte libre

  Les champs qui alimentent des filtres ou des tableaux croisés sont des énumérations : catégorie, domaines, épreuves, codes de compétence, types de preuve, état de publication. Une valeur hors liste ou un champ inconnu arrête le build. Une faute de frappe sur un code de compétence ne peut donc pas produire silencieusement une case vide dans la matrice.

• Registre des technologies, non affiché par défaut

  Le catalogue des technologies sert de liste de choix, mais chaque entrée y est marquée non confirmée par défaut et n'apparaît nulle part sur le site tant qu'elle n'a pas été explicitement confirmée et accompagnée d'une note décrivant l'usage réel qui en a été fait. C'est le point du projet où la tentation d'aligner des logos est la plus forte.

• Preuves déclarées avant d'être disponibles

  Une preuve possède un état : disponible ou à fournir. Une preuve annoncée mais absente reste visible sur la fiche, sur la page de compétence et dans le registre documentaire, avec la mention correspondante. Déposer le fichier dans public/documents/ et basculer l'état active le lien partout où la preuve est référencée.

Procédures

• Ajouter une réalisation sans toucher à l'interface

  Copier le modèle commenté depuis docs/modeles/ vers src/content/realisations/, renommer le fichier (son nom devient l'URL), remplir le frontmatter puis le corps Markdown. Aucun composant n'est modifié. Le modèle documente chaque champ et ses valeurs admises, ce qui permet de rédiger une fiche sans relire le schéma.

• Une branche et une pull request par modification

  Aucune modification n'est poussée directement sur la branche principale. Chaque ajout ouvre une branche nommée par son objet, puis une pull request relue avant fusion. L'historique donne ainsi la chronologie réelle du projet, ce qui est directement exploitable pour justifier le travail en mode projet.

Environnement

• Serveur de développement ORCA-SERV : VPS Ubuntu personnel rejoint par réseau privé maillé, où sont centralisés les dépôts et les agents de code
• Astro 7 en sortie statique, TypeScript strict, Node 20+
• Claude Code (Anthropic) comme assistant de développement en binôme
• Git et GitHub, dépôt EPS-AXIANS/portfolio-bts-sio-sisr
• Lighthouse pour les mesures de performance, d'accessibilité et de référencement

Technologies

• Astro
• TypeScript
• Node.js
• Git

Tests réalisés

• Contrôle de types et de contenu au build

  La commande de build enchaîne la vérification de types et la génération. Sortie obtenue : zéro erreur et zéro avertissement. Le même contrôle valide les fichiers Markdown contre leurs schémas, ce qui fait échouer le build sur une fiche mal renseignée plutôt que de publier une page incohérente.

• Revue de toutes les routes, une à une

  Chaque route a été ouverte et contrôlée, seize à la date de la recette : aucune erreur en console, un seul titre de premier niveau par page, titres et descriptions uniques, aucun débordement horizontal, tous les liens internes résolus.

• Mesures Lighthouse sur trois pages représentatives

  Accueil, page de compétences et une fiche de réalisation. Profil bureau : 100 en performance, accessibilité, bonnes pratiques et référencement. Profil mobile : 100 partout sauf la performance, mesurée entre 97 et 100 selon la charge de la machine de mesure sous bridage processeur.

• Comportement sans JavaScript

  Navigation complète du site avec les scripts désactivés : la matrice de compétences affiche tous ses panneaux légendés et empilés, la bibliothèque toutes ses cartes. Les commandes qui seraient inertes, onglets et filtres, ne s'affichent pas du tout, plutôt que de rester visibles sans effet.

Résultats obtenus

• Une URL directe par réalisation, ouvrable pendant une soutenance ; toutes les routes contrôlées une à une.
• Vérification de types et de contenu : zéro erreur, zéro avertissement.
• Lighthouse : 100 sur les quatre axes en profil bureau ; 97 à 100 en performance mobile, 100 sur les trois autres axes.
• Aucun fichier JavaScript produit au build : les trois îlots interactifs sont intégrés au HTML des seules pages qui les utilisent.
• Aucune requête vers un domaine tiers : deux polices auto-hébergées pour 29 Ko au total, images converties au build.
• Ajout d'une réalisation, d'une preuve ou d'un article de veille par dépôt d'un seul fichier, sans modification de composant.
• Documentation d'exploitation du dépôt rédigée : où modifier quoi, comment ajouter une fiche, comment déposer une preuve.

Difficultés rencontrées et solutions apportées

• Le risque propre au travail avec une IA : le plausible qui passe pour du vrai

  Un assistant produit sans effort une phrase crédible sur une technologie que je n'ai jamais mise en œuvre, ou une date vraisemblable. C'est le risque principal de ce mode de travail, et il ne se corrige pas par la vigilance seule. La réponse a été structurelle : les jetons « À COMPLÉTER » restent affichés sur le site, et les technologies sont masquées tant qu'elles ne sont pas confirmées une par une. Le catalogue a d'ailleurs été livré entièrement non confirmé, puis ouvert dans un second temps aux seules briques réellement mises en œuvre, avec la note d'usage correspondante.

• Déléguer l'écriture sans déléguer la responsabilité

  Devant un jury, c'est moi qui réponds. Une fiche que je n'aurais pas relue ligne à ligne serait indéfendable à l'oral, quelle que soit sa qualité d'écriture. La règle que je me suis fixée est simple : je relis chaque modification avant fusion, et tout ce qui me concerne (parcours, rôle, difficultés rencontrées) vient de moi, jamais de l'assistant. Le gain de temps est réel sur l'implémentation et la mise en forme ; il est nul sur le contenu, et c'est normal.

• L'interactivité pensée après coup dégrade mal

  Une matrice de compétences en onglets et une bibliothèque à filtres sont naturelles à écrire en supposant que les scripts s'exécutent. Sans eux, on obtient une page où tout est masqué et des boutons qui ne font rien. Le parti retenu a été l'inverse : l'état sans JavaScript est l'état par défaut, tous les panneaux sont visibles, et les commandes ne sont ajoutées que lorsqu'elles peuvent fonctionner. Cette décision doit être prise en écrivant le composant, pas après.

Bilan

Ce projet est le seul du portfolio dont le portfolio lui-même est le livrable, et c'est ce qui le rend intéressant : les décisions y sont visibles dans le résultat. Ce que j'en retiens tient surtout au mode de travail. Développer en binôme avec un assistant d'IA déplace l'effort : il passe de l'écriture du code vers la spécification, la relecture et la vérification. L'effort reste le même en quantité, il change simplement de nature, et il demande de savoir précisément ce que l'on veut avant de le demander. La contrepartie est un risque que je n'aurais pas eu seul : un texte fluide et faux se repère beaucoup moins bien qu'une erreur de syntaxe, et c'est pour cela que les garde-fous sont dans le code plutôt que dans mes intentions. Le site reste à déployer : l'URL de production n'est pas encore renseignée, et une partie des fiches attend le contenu réel de l'alternance.

Liens