Mise en ligne de mon portfolio professionnel

Seul, du 20 septembre au 12 novembre 2026. Projet personnel au service de l’épreuve E5 ; le serveur est hébergé chez moi. Mise en ligne le 12 novembre.

Compétences mises en œuvre

Compétence	Ce que j’ai fait	Preuve
Organiser son développement professionnel
Gérer son identité professionnelle	Un portfolio public sous mon nom, relié à mon profil LinkedIn et à mon compte GitHub ; ce qui est publié est choisi : clients d’OMB anonymisés, rien de mon réseau personnel	mise en œuvre, figure 1, le site en ligne
Développer son projet professionnel	Mon projet écrit et daté sur la page Parcours : BTS en 2027, Bachelor Cybersécurité et Administrateur Réseau en alternance chez OMB, puis la piste DevOps avec deux certifications choisies	mise en œuvre, page Parcours

Contexte et besoin

À l’épreuve E5, le jury consulte mon portfolio pour lire mes réalisations et leurs preuves. Un portfolio inaccessible coûte 10 points sur 20. Depuis septembre, le site existait sur mon poste : on ne pouvait le voir que chez moi, en aperçu local.

Le besoin : un site joignable par une adresse stable, en HTTPS, qui ne soit pas référencé par les moteurs de recherche, et que je peux mettre à jour en une commande. Le portfolio est aussi ma vitrine : il doit dire qui je suis et où je vais.

Objectifs et contraintes

Objectifs

Publier le portfolio sur Internet, en HTTPS, à une adresse que je peux donner au jury.
Mettre à jour le site en une commande, sans jamais laisser un site à moitié copié.
Présenter une identité professionnelle cohérente : même nom et mêmes liens partout.
Écrire mon projet professionnel comme un plan, avec des étapes et des dates.

Contraintes

Non référencé : le jury accède au site par son adresse ; le public n’a pas à le trouver.
Confidentialité : clients d’OMB anonymisés, aucun détail sensible sur OMB, rien de mon réseau personnel.
Sans dépendance : lisible sans JavaScript et copiable sur une clé USB en secours.
Pas de nouveau service à payer : j’héberge le site sur mon matériel, avec mon nom de domaine et mon reverse proxy.

Analyse et choix techniques

Question	Mon choix	Pourquoi
Quel outil pour le site ?	Hugo, générateur de site statique, à partir de fichiers Markdown	Pas de base de données ni de code côté serveur à sécuriser ; le site se copie tel quel sur une clé USB
Où l’héberger ?	Une VM (machine virtuelle) Debian 13 sans interface graphique, chez moi, avec le serveur web nginx	Je maîtrise la machine de bout en bout ; un serveur sans interface a moins de logiciels à tenir à jour
Comment le publier ?	Par mon Nginx Proxy Manager, qui reçoit déjà les connexions web de la maison, sous une adresse à mon nom de domaine	Le reverse proxy porte le nom public et le HTTPS ; la VM n’est pas exposée directement
Comment l’envoyer ?	Le script deploy.sh : construction, archive envoyée par SSH (connexion chiffrée), dépliée dans un dossier neuf puis échangée d’un coup avec l’ancien	Le jury ne voit jamais un site à moitié copié ; rsync n’existe pas sous Windows, tar et SSH oui
Avec quel compte ?	Un compte d’envoi dédié, connexion par clé seulement, sans droits d’administration ; adresse et clé hors du dépôt	Si la clé fuit, elle ne permet que de déposer le site
Comment éviter le référencement ?	Un en-tête noindex sur chaque page, pas de plan du site	Accessible par l’adresse, absent des moteurs de recherche
Quelle identité montrer ?	Mon nom, mes liens LinkedIn et GitHub dans le pied de chaque page ; mon parcours de reconversion assumé	Un recruteur ou un jury retrouve la même personne partout

Ce que j’en retiens : un portfolio est un service comme un autre : il a une adresse, un certificat, une procédure de mise à jour et un plan de secours. Ce qu’il montre de moi se choisit aussi soigneusement que ce qu’il cache.

Mise en œuvre

Schéma : le portfolio en ligne, de la construction du site sur mon poste à son hébergement chez moi puis à sa publication par le reverse proxy, et ce qu’il dit de mon identité et de mon projet professionnels

Figure 1 · Le portfolio en ligne : construction, hébergement, publication, et ce qu’il dit de moi.

Le schéma suit le chemin d’une mise à jour, de mon poste au jury. Les étapes, dans l’ordre :

Le cadrage (24 septembre) : site accessible par son adresse mais non référencé, clients anonymisés, seule l’infrastructure du laboratoire de l’école publiée, tableau de synthèse téléchargeable au format officiel.
Le contenu : une page par réalisation E5 à partir de mes fiches, les pages E6, la veille, et les pages du laboratoire synchronisées depuis sa documentation.
Le projet professionnel (10 novembre) : la page Parcours, rédigée à partir de mes réponses : ce que je faisais avant, l’entreprise et ma place, ma progression, mon laboratoire et mon projet.
Le retrait des détails sensibles (12 novembre) : avant la publication, les pages qui touchent OMB et ses clients ont été relues ; quatre détails retirés, deux schémas refaits.
L’hébergement (12 novembre) : j’ai choisi une VM Debian 13 chez moi, publiée par mon Nginx Proxy Manager ; serveur web nginx, compte d’envoi à clé seule, sans droits d’administration.
L’envoi : le script deploy.sh construit le site, l’envoie par SSH, l’échange d’un coup et vérifie la page d’accueil sur la VM.
La publication : l’adresse déclarée dans le reverse proxy, avec un certificat et la redirection de http vers https ; vérifiée depuis Internet le jour même.

Mon projet professionnel, tel que la page Parcours le présente :

Quand	Étape	Ce qu’elle m’apporte
2015 à 2025	Près de dix ans en grande distribution, dont du management	Gestion d’équipes de 12 à 16 personnes, pilotage par indicateurs, sens du service client
Novembre 2025	Entrée en BTS SIO option SISR	La reconversion vers l’administration systèmes et réseaux
Juin à septembre 2026	Stage chez OMB Informatique	Le terrain : tickets, atelier, déploiement de postes ; le stage débouche sur l’alternance
Depuis septembre 2026	Alternance chez OMB, laboratoire de l’école	La production chez des clients d’un côté, l’expérimentation de l’autre
Session 2027	Épreuves du BTS	E5 et E6 devant le jury
Après le BTS	Bachelor Cybersécurité et Administrateur Réseau, en alternance chez OMB	Approfondir l’administration et la cybersécurité
Plus tard	Piste DevOps : certifications HashiCorp Terraform Associate et CKA (administration de Kubernetes)	Décrire une infrastructure sous forme de code, administrer des conteneurs

Tests et recette

Test (depuis Internet, 12 novembre)	Résultat
Page d’accueil en HTTPS	Réponse 200
Adresse en http	Redirection permanente (301) vers https
Certificat	Valide jusqu’au 31 décembre 2026
Référencement	En-tête « noindex, nofollow » présent
Brouillons	Absents du site publié
Envoi par deploy.sh	Site échangé d’un coup ; page d’accueil vérifiée sur la VM après l’envoi

Bilan critique

Ce qui a coincé. La relecture avant publication a montré que des détails anodins dans une fiche pouvaient, une fois publiés, révéler des faiblesses d’une entreprise ou relier deux interventions chez le même client. Les pages concernées ont été corrigées avant la mise en ligne, et mes fiches sources dans le même sens.

Les limites que j’assume.

Le nom de domaine passe par Cloudflare : le certificat vu par le visiteur est celui de Cloudflare, et son outil de statistiques ajoute un script aux pages ; je dois le couper.
Le serveur est chez moi : une coupure de courant ou d’Internet à la maison rend le site injoignable. La copie hors ligne sur clé USB est le plan de secours.
La page Parcours garde une partie à écrire avec mes mots : ce que mes premières interventions m’ont fait comprendre.

Ce que je referais autrement. Je relirais les pages sous l’angle de la confidentialité dès leur écriture, et non à la veille de la publication.

Outils et aides. Les choix et les décisions de cette réalisation sont les miens (hébergement, adresse, ce qui est publié, contenu de mon parcours et de mon projet). Un assistant IA (Claude Code) a écrit une partie du site et des scripts, et m’a aidé à rédiger les pages à partir de mes réponses, que j’ai relues.