Ce portfolio — concevoir et développer le site qui atteste mes compétences

Au départ, mon portfolio était un document Word. Portfolio_TomEGE_v5.docx : 11,4 Mo, 609 lignes de texte utile, 11 visuels intégrés. Il n'était pas organisé par projet mais par année, puis par unité d'enseignement, puis par projet. Ça a l'air d'un détail de mise en page. C'en est un de fond.

Parce que dans cette organisation, un projet ne peut appartenir qu'à une seule compétence à la fois. Ma SAÉ 302, le MMI LAN, apparaît trois fois dans le document : une fois sous Comprendre, une fois sous Concevoir, une fois sous Exprimer. Trois versions du même projet, chacune amputée de ce que les deux autres racontent. Un lecteur qui tombe sur l'une des trois ne voit qu'un tiers du travail. Le format m'obligeait à découper ce qui, dans la réalité, était un seul chantier.

Le site en ligne que j'avais à côté ne réglait rien : ses fiches étaient maigres. Deux paragraphes, une image quand il y en avait une, et une liste de codes d'apprentissages critiques posés là sans que rien ne les explique. J'ai fait le compte au moment de démarrer : sur 47 rattachements entre une réalisation et un AC, 23 n'avaient aucun texte de justification, et la longueur médiane des autres était de 123 caractères. Une ligne. Devant un jury, une case cochée que rien n'explique appelle exactement la même question qu'une case vide.

D'où la commande que je me suis passée à moi-même. Un site où l'unité n'est pas la page mais le lien entre une réalisation et un apprentissage critique, avec le texte qui explique ce lien. Une réalisation, autant d'AC qu'elle mobilise réellement, et pour chacun une justification rédigée qui tient debout toute seule. Le reste — la grille, les filtres, la mise en page — découle de ça.

Trois contraintes encadraient le chantier. Je devais pouvoir modifier le contenu sans ouvrir un éditeur de code, parce qu'un portfolio se corrige la veille d'un oral et que je ne voulais pas dépendre d'un déploiement pour changer un mot. L'hébergement, un Plesk sous nginx sur tomege.wstr.fr, ne construit rien côté serveur : on y dépose des fichiers en FTP, point. Et le budget était nul, donc tout devait tenir en logiciel libre ou en palier gratuit.

Le calendrier a été court et découpé en sessions : une première nuit de travail fin juillet 2026 pour sortir une version complète et déployable, puis deux passages en août pour densifier le contenu — le dernier le 27 août, la veille de la soutenance.

Disséquer le document Word avant d'écrire une ligne de code

J'ai commencé par extraire le .docx plutôt que de le relire. Un fichier Word est une archive ZIP qui contient un word/document.xml : un script Python le dézippe, en tire le texte brut et les visuels, et produit un fichier lisible dans docs/docx-extrait.md. Ça m'a pris moins de temps que de recopier à la main, et surtout ça m'a donné une base fixe : à partir de là, je travaillais sur une source que je pouvais relire, chercher, comparer.

Cette lecture a sorti deux choses. La première, les 14 réalisations réelles derrière les 16 entrées « PROJET » du document, avec pour chacune l'année, l'équipe, les outils, le visuel et le lien quand ils existaient — 7 sur 14 n'avaient pas de visuel, 8 sur 14 pas de lien. La seconde, un schéma rédactionnel que je suivais sans l'avoir formalisé : contexte, processus, compétences acquises, auto-évaluation, auto-critique, continuité. Six temps, systématiques. Le cahier des charges que j'avais en tête prévoyait plutôt un triptyque contexte / démarche / résultats. J'ai gardé mes six temps : réduire l'auto-critique et la continuité à un champ « résultats » aurait fait disparaître exactement ce qui est évalué en MMI.

Modéliser : la table de jonction est le cœur du projet

Le modèle compte une vingtaine de collections — réalisations, apprentissages critiques, compétences, univers, outils, types, expériences, savoir-faire, pages, ressources, SAÉ, notes, chiffres clés, liens sociaux, textes d'interface, paramètres — plus quatre tables de jonction.

Une seule décision compte vraiment. La table qui relie une réalisation à un apprentissage critique porte un champ justification. Le texte qui explique en quoi telle réalisation prouve tel AC n'est ni dans la réalisation, ni dans l'AC : il est dans le lien, parce qu'il n'existe que par le lien. C'est ce qui rend le portfolio différent d'une liste de projets avec des étiquettes. Et c'est la raison principale du choix de Directus : il expose nativement les champs d'une table de jonction dans une interface éditable, ce que beaucoup de CMS ne savent pas faire.

Deuxième décision structurante : univers est une relation multiple, pas un champ unique. Ma fiche « Auto-entrepreneur créateur de contenu » est à la fois une trace de l'UE Entreprendre de BUT 1 et une activité Nexan. La présidence de JKMC est à la fois une trace académique et l'association. Avec un univers unique, mes deux meilleures preuves d'Entreprendre disparaissaient soit du tableau de bord académique, soit des pages Nexan et JKMC. J'ai gardé en plus un univers_principal, pour savoir quoi afficher quand il n'y a la place que pour un.

Choisir la pile en partant de l'hébergement

L'hébergement ne construit rien : le site devait donc être entièrement statique. J'ai pris Eleventy 3 avec des gabarits Nunjucks pour la génération, et Directus 12 sur base SQLite en local pour l'administration. Le build interroge l'API une fois, écrit du HTML, et c'est fini. Une fois en ligne, le site ne fait plus aucun appel réseau : il reste debout même si le CMS est éteint.

J'ai écarté WordPress, que je connais pourtant et que j'ai utilisé sur d'autres projets. Pour ce besoin précis — une table de jonction éditable, un référentiel de 75 AC, des relations multiples partout — il aurait fallu un empilement d'extensions, et j'aurais fini par ne plus maîtriser ce que je livrais. Sur mon propre portfolio, c'était le mauvais compromis.

Toute la configuration de Directus est écrite dans un script plutôt que cliquée dans l'interface : schéma, champs, trois rôles, notes d'aide, icônes, marque-pages, bouton de publication. Le script est rejouable et non destructeur — il crée ce qui manque et ne touche pas à l'existant. Concrètement, je peux recréer une instance vierge et retrouver mon administration à l'identique, ce qui est ce dont j'ai eu besoin le jour où je suis passé de SQLite à une base de production.

Sortir tous les textes du code

C'est le parti pris que je défends le plus. Aucun texte visible n'est écrit en dur dans les gabarits. Pas seulement les articles et les fiches : les surtitres, les libellés de boutons, les étiquettes de formulaire, les messages d'état. Tout vit dans une collection textes_site, appelée depuis les gabarits par une clé.

Le raisonnement est simple : dès qu'une phrase est dans le code, elle est hors de ma portée quand je n'ai pas l'environnement sous la main. Un filtre absorbe les cas tordus — clé manquante, texte vide, jeton de remplacement non fourni — sans jamais interrompre la génération, mais en listant les manques à la fin du build. Un portfolio ne doit pas cesser de se construire parce qu'un libellé manque ; il doit me dire lequel manque.

J'ai buté sur un piège en chemin : mon premier filtre lisait les textes depuis le contexte du gabarit, et rendait des chaînes vides partout dès qu'il était appelé depuis une macro — une macro Nunjucks ne reçoit que ses arguments, pas les données globales. Les textes sont maintenant chargés une fois dans un cache de module, avant la génération.

La direction artistique, puis l'accessibilité qui la corrige

Direction retenue : néo-brutalisme éditorial. Fond blanc dominant, rose #FF2E88, jaune #FFD400, noir, bordures franches et ombres dures décalées. Tiré vers « propre et pro » plutôt que vers le chaos, parce que le lecteur visé est un jury, pas un feed.

L'audit de contraste a démoli une partie du premier jet, et c'est la meilleure chose qui soit arrivée à la charte. Les pastilles de compétence étaient en texte blanc sur aplat vif : 2,91:1 sur le cyan, 2,62:1 sur le vert, contre 4,5:1 exigés. Je les ai passées en texte noir sur fond clair, 13:1 au minimum, avec l'accent vif conservé en anneau intérieur — le code couleur reste lisible, le contraste passe, et je n'ai plus d'exception à gérer pour le jaune. Le rose vif avec du blanc ne donne que 3,50:1, donc dès qu'il y a du texte j'utilise un rose foncé à 4,89:1, et je garde le rose vif pour les surfaces sans texte.

L'anneau de focus m'a demandé le plus de tâtonnements. Aucune couleur unique ne ressort à la fois sur blanc, sur rose, sur jaune et sur le pied de page noir — le bleu franc que j'avais mis tombait à 1,58:1 sur le rose. La solution est un anneau noir doublé d'un halo blanc, qui s'inverse dans le pied de page. Le jaune, lui, n'est jamais utilisé pour du texte, nulle part.

Deux règles que je me suis imposées : aucun état ne repose sur la seule couleur — un AC non attesté cumule une mention écrite, une bordure en pointillés et un fond grisé — et les blocs à apparition sont visibles par défaut, c'est le JavaScript qui active l'état masqué. Jamais l'inverse. Si le script ne se charge pas, le contenu est là.

Performance : décider ce qu'on paie et ce qu'on économise

Le CSS est écrit en six couches — variables, base, mise en page, composants, pages, utilitaires — concaténées et minifiées en un seul bloc injecté directement dans le <head>. Résultat : zéro ressource bloquante, zéro décalage de mise en page. Le compromis est réel et je l'assume : pas de cache entre les pages, environ 8 Ko compressés retéléchargés à chaque navigation. Sur un site de 96 pages où la première impression compte plus que la dixième, je préfère payer ça.

Les images sont téléchargées depuis le CMS au build, converties en AVIF et WebP avec repli JPEG, en plusieurs largeurs, avec chargement différé sauf l'image d'en-tête des fiches. Les dimensions sont écrites sur chaque image, ce qui supprime tout sursaut au chargement. Les polices sont auto-hébergées en woff2 plutôt que servies par Google : une requête tierce de moins, et aucune adresse IP de visiteur transmise à un tiers.

Côté référencement : titre et description par page, URL canonique, Open Graph, sitemap, données structurées Person partout et CreativeWork sur chaque fiche. Les images de partage sont fabriquées au build et déposées sur le site, parce que mes balises pointaient d'abord sur le CMS, injoignable depuis l'extérieur — un lien partagé s'affichait sans vignette.

Se fabriquer des instruments de mesure

Trois scripts maison, et c'est peut-être ce dont je suis le plus content.

L'audit passe sur le site généré et vérifie les textes alternatifs, la hiérarchie des titres, les champs de formulaire étiquetés, les noms accessibles des zones de navigation, la validité du JSON-LD, la longueur des titres et des métadescriptions, et 24 couples de contraste de la charte. Il a attrapé des bêtises que je n'aurais jamais vues : des titres de fiches d'AC montant à 204 caractères, et son propre bug — il comptait ' pour cinq caractères, ce qui faisait paraître mes titres français bien plus longs qu'ils ne le sont réellement pour un moteur.

La matrice de couverture recalcule, à la demande, l'état de chaque AC du référentiel. J'ai refusé le découpage à trois états que j'avais prévu au départ, et j'en ai mis quatre : attesté, à renforcer, déclaré sans preuve, aucune trace. L'état « déclaré sans preuve » était invisible dans le découpage à trois, alors que c'est le plus traître — une case cochée que rien n'explique. Le fichier est réécrit à chaque exécution, c'est un instrument, pas un document.

Le script de livraison reconstruit, contrôle et emballe. Il refuse de produire l'archive si le build contient une URL localhost, ou si une seule des 1 629 références internes du site pointe dans le vide. Le premier contrôle m'a évité une mise en ligne où 60 pages avaient des liens canoniques et un sitemap pointant sur ma machine de développement.

Un système de migrations, parce que le seed ne suffisait pas

Mon script d'installation crée ce qui manque et ne touche à rien d'existant. Très bien pour installer, inutile pour corriger une donnée déjà en base. J'ai donc écrit un mécanisme de migrations : chaque évolution du contenu est un fichier numéroté qui expose une fonction pour appliquer et une pour annuler, l'historique est stocké dans le CMS, et une migration déjà passée n'est jamais rejouée. Douze à ce jour.

Règle que je me suis donnée et qui a compté : une migration ne remplit que ce qui est vide. Un champ déjà rempli dans l'administration est laissé tel quel. Le texte que j'écris à la main prime toujours sur celui d'un script.

Se regarder soi-même comme un objet de conception

C'est la partie que je n'avais pas anticipée. Concevoir un portfolio qui doit attester des compétences, ce n'est pas mettre en page des projets : c'est décider quoi montrer, dans quel ordre, avec quel niveau de détail, et vivre avec ce qu'on décide de laisser dehors.

Quelques arbitrages concrets. Le bloc réflexif « Ce que j'en retire » était replié derrière un dépliant : je l'ai ouvert par défaut, parce que c'est la seule section qui expose une démarche et que c'est ce qu'un jury retient. Les champs vides ne sont jamais remplis de faux contenu — une réalisation sans visuel affiche un bloc typographique qui dit visiblement « pas d'image » plutôt qu'un espace réservé qui ressemble à un bug, et une réalisation sans lien le dit en toutes lettres. J'ai aussi ajouté une page /parcours-guide/, volontairement hors du menu : le fil de mon oral, sept traces, dix-huit minutes, les AC de chacune. Elle n'est pas faite pour être trouvée, elle est faite pour être suivie.

Chiffres relevés le 27 août 2026, sortis de mes propres outils : la commande d'audit, la matrice de couverture, et l'inventaire produit par le script de livraison.

Ce que le site contient

• 96 pages HTML générées, 93 URL déclarées au sitemap.
• 26 réalisations publiées, contre 14 au départ.
• 97 rattachements entre une réalisation et un apprentissage critique, contre 47 au départ.
• 0 rattachement sans justification écrite, contre 23 au départ. Longueur médiane des justifications : 465 caractères, contre 123 avant.
• 60 fiches d'apprentissage critique générées sur les 75 du référentiel en base — seuls les AC réellement attestés ont une page.
• 19 AC solidement attestés, contre 0 au moment du diagnostic initial.

Accessibilité et qualité

• Aucune anomalie sur les 96 pages au dernier passage de l'audit : pas de texte alternatif manquant, pas de niveau de titre sauté, pas de champ de formulaire sans étiquette, pas de JSON-LD invalide.
• 24 couples de contraste sur 24 conformes au niveau AA de WCAG 2.1.

Performance

• Décalage cumulé de mise en page : 0. Aucune ressource bloquante.
• Page d'accueil : 101 Ko transférés, 10 requêtes, polices servies en 3 ms.
• CSS : 39 Ko minifié, injecté en ligne. JavaScript : 15 Ko, en modules ES, zéro dépendance.
• Images : 2,06 Mo d'AVIF contre 10,88 Mo de PNG source, soit 81 % de moins.
• Testé à 375, 768 et 1440 pixels de large : aucun débordement.

Livraison

L'archive du 27 août 2026 contient 460 fichiers, 22,1 Mo compressés pour 27,2 Mo une fois déposés, avec son empreinte SHA-256 et son inventaire par type. Elle n'est produite qu'après vérification qu'aucune URL localhost ne subsiste et que les 1 629 références internes du site résolvent toutes vers un fichier réellement présent.

Un incident vaut d'être cité parce qu'il illustre ce que ces contrôles servent à attraper. La commande d'archivage native de Windows PowerShell écrit les chemins du ZIP avec des antislashs, ce qui viole le format : mesuré sur ce projet, 239 entrées sur 277. Un serveur Linux décompresse alors un fichier nommé littéralement realisations\index.html à la racine, et le site est cassé sans que rien ne l'explique. J'ai remplacé l'archivage par une bibliothèque qui normalise les séparateurs, puis testé l'extraction et navigué le site depuis l'archive.