AnisAnis MEZDARIMEZDARI

Dates

début le 15/09/2026 · phase 1 à rendre avant le lundi 28/09/2026 · fin du projet : non fixée

Organisation

équipe de 4 ; phases 1 et 2 en individuel, phases 3 à 5 en équipe · rôle dans l'équipe : chef de projet, chargé de répartir les tâches (le travail en équipe commence à la phase 3)

Contexte

Cas d'étude fictif donné en cours. L'ESN Art-Tech Solutions a pour client la DMPC du Musée du Louvre, dont les conservateurs veulent se faire aider par une IA pour rédiger des fiches pédagogiques. Un service cloud public est exclu : les textes peuvent contenir des recherches non publiées ou les plans qui protègent les œuvres. Le service doit donc tourner sur l'infrastructure du musée, sans l'affaiblir.

Le projet est découpé en cinq phases :

Objectifs (phase 1)

Le cahier des charges demande une plateforme stable, fermée aux accès non autorisés. Je me suis fixé cinq points :

• un système minimal : Debian installée sans interface graphique ;
• une seule porte d'entrée : SSH, déplacé sur un port non standard, par clé RSA de 4096 bits et sans mot de passe ;
• un pare-feu qui refuse tout en entrée, sauf SSH depuis le réseau d'administration ;
• des droits limités au besoin : un administrateur nominatif, un compte d'exploitation restreint, root inaccessible ;
• une installation vérifiée : tests de recette et audit Lynis.

Architecture

Le serveur à la fin de la phase 1 :

• Hôte : VirtualBox 7.2.
• VM : Debian 13 « Trixie » (noyau 6.12), 4 vCPU, 8 Go de RAM, disque de 20 Go, carte réseau en mode pont (la VM apparaît comme une machine du réseau local).
• Sur la VM : OpenSSH (clés uniquement, port non standard), UFW (règles appliquées par nftables via iptables-nft), Fail2ban, sudo.
• Flux autorisé : SSH depuis le réseau d'administration, en IPv4 et en IPv6. Tout autre trafic entrant est refusé ; le trafic sortant est autorisé.

Technologies

• Debian 13 « Trixie », noyau 6.12 : installation minimale
• VirtualBox 7.2 : hyperviseur de test
• OpenSSH : connexion par clé RSA de 4096 bits
• UFW, avec nftables via iptables-nft : pare-feu
• Fail2ban : blocage des tentatives répétées
• sudo, sudoers, visudo : gestion des privilèges
• Lynis : audit de durcissement

Étapes

1. Machine virtuelle. J'ai créé la VM sous VirtualBox 7.2 (4 vCPU, 8 Go de RAM, 20 Go de disque, réseau en pont), puis installé Debian 13 en version minimale, sans interface graphique.
2. Accès SSH. J'ai déplacé SSH sur un port non standard et fermé le port 22. L'authentification se fait uniquement par clé : PasswordAuthentication no, RequiredRSASize 4096. J'ai régénéré la clé d'hôte RSA du serveur en 4096 bits. La connexion de root est interdite (PermitRootLogin no) et SSH est réservé à un groupe (AllowGroups).
3. Pare-feu. Avec UFW, tout est refusé par défaut en entrée et autorisé en sortie. Seul SSH est ouvert, uniquement depuis le réseau d'administration, en IPv4 comme en IPv6. Sous Debian 13, UFW passe par iptables-nft : ce sont les règles nftables qui s'appliquent.
4. Fail2ban. Trois échecs en 10 minutes valent un bannissement de 2 heures, appliqué par UFW.
5. Privilèges.
   • Administrateur nominatif dans le groupe sudo : tous les droits, mais le mot de passe est exigé.
   • Compte d'exploitation exploit-ia : il peut seulement consulter l'état des services et redémarrer certains d'entre eux. apt et le shell root lui sont refusés, et je l'ai testé.
   • root : mot de passe verrouillé, pas de connexion SSH.
   • Fichiers de /etc/sudoers.d/ vérifiés avec visudo, chemins absolus, aucun caractère joker.
   • Journal dédié /var/log/sudo.log ; le mot de passe est redemandé après 5 minutes.
6. Recette. 10 tests, tous validés. Par exemple : connexion par clé acceptée, mot de passe refusé, root refusé, compte inconnu refusé, apt et shell root refusés pour exploit-ia.
7. Audit. Lynis, lancé avant puis après le durcissement : l'indice de durcissement passe de 66 à 73.

Livrables

• VM Debian 13 durcie : SSH par clés, UFW, Fail2ban, sudoers.
• Recette de 10 tests, tous validés.
• Rapports Lynis avant / après (indice 66 → 73).

Bilan

Compétences E5 visées

Gérer le patrimoine informatique · Travailler en mode projet · Mettre à disposition des utilisateurs un service informatique

Adresse

https://portfolio.pawanis.com (pawanis.com et www y redirigent)

Organisation

projet individuel

Contexte

Le jury consulte ce portfolio avant et pendant l'oral E5, et mon CV y renvoie.

Objectifs

• Un site rapide et accessible, lisible sur téléphone comme sur ordinateur.
• Une adresse à mon nom, en HTTPS.
• Le respect du cadre juridique : mentions légales, aucun cookie, adresse e-mail cachée aux robots.
• Aucune donnée interne à Thales : des descriptions génériques, vérifiées avant chaque mise en ligne.
• Un bon référencement : les moteurs de recherche n'indexent que l'adresse officielle.

Architecture

Site statique : une page HTML, une feuille de style, un script, sans framework ni base de données.

Technologies

• HTML
• CSS
• JavaScript (sans framework)
• Cloudflare DNS
• Cloudflare Pages
• Wrangler
• Namecheap
• Python (contrôles)
• Canva (CV)

Étapes

1. Nom de domaine. pawanis.com, enregistré chez Namecheap.
2. DNS. J'ai confié la zone pawanis.com à Cloudflare, en remplaçant les serveurs de noms chez Namecheap.
3. Hébergement. Projet Cloudflare Pages, mis en ligne avec Wrangler, l'outil en ligne de commande de Cloudflare. Le sous-domaine portfolio.pawanis.com a son certificat HTTPS.
4. Redirections. Une règle Cloudflare renvoie pawanis.com et www.pawanis.com vers le portfolio (redirection 301).
5. Sécurité. En-têtes HTTP : CSP (seuls les scripts et styles prévus sont acceptés), HSTS (HTTPS obligatoire), X-Frame-Options, nosniff, Referrer-Policy et Permissions-Policy.
6. Cadre juridique. Mentions légales (éditeur, hébergeur), aucun cookie ni mesure d'audience, polices hébergées sur le site : aucun service tiers ne voit les visiteurs. L'adresse e-mail est assemblée par le script, pour la cacher aux robots qui collectent les adresses.
7. Référencement. Plan du site (sitemap.xml), adresse canonique, et l'adresse technique pawanis.pages.dev exclue de l'index.
8. Contrôles. Avant chaque mise en ligne, un script Python vérifie plus de 40 règles : performance, accessibilité, aucune adresse IP ni port SSH publiés.

Livrables

• Le site en ligne : https://portfolio.pawanis.com.
• Les mentions légales et le CV téléchargeable.
• Le tableau de synthèse E5, consultable sur le site.

Bilan

Compétences E5 visées

Développer la présence en ligne de l'organisation · Organiser son développement professionnel

Accès

site privé, protégé par mot de passe ; montré à l'oral

Organisation

projet individuel

Contexte

J'ai d'abord tenu ma veille à la main, deux semaines : ouvrir une trentaine de sites tous les jours prend une heure. Un lecteur de flux ne règle rien : il rend des centaines de titres qu'on finit par ne plus ouvrir. J'ai donc construit le système qui trie et rend compte.

Objectifs

• Garder une trace écrite et datée de ce que j'ai lu, pour la retrouver des mois plus tard.
• Administrer la machine de bout en bout : installation, sécurité, sauvegarde, dépannage.
• Ne rien envoyer à un service payant : le texte des articles ne sort pas de la machine.

Architecture

Une seule machine, quatre pièces et une base :

Le site

Python et Flask : il sert les pages, porte l'API interne et déclenche le relevé de 6 h 30

n8n

le chef d'orchestre du rapport, en conteneur : il relance un relevé, demande un résumé par article, puis la synthèse, et poste le résultat

Ollama

exécute le modèle Hermes 3 sur la machine, dans un second conteneur

SQLite

un seul fichier, six tables : les sources, les articles, les relevés, les rapports

Le conteneur du modèle est sur un réseau Docker sans route vers l'extérieur : Hermes 3 ne peut ni sortir, ni être joint depuis le réseau local. n8n est le seul à avoir un pied dehors, pour poster le rapport dans un salon Discord privé. Le site passe par un tunnel sortant et demande un mot de passe.

Rythme

Le relevé part seul tous les matins à 6 h 30, heure de Paris, et dure de 19 à 27 secondes. Le rapport est rédigé le lundi et le jeudi à 7 h : tous les jours, ce serait une demi-heure de calcul pour une seule journée d'actualité ; une fois par semaine, une faille critique attendrait sept jours.

n8n tient ce rendez-vous : chaque étape se voit et se rejoue quand elle échoue, les temps d'attente sont réglés sur un pire cas d'environ une heure sans carte graphique, et un second scénario prévient dès qu'une exécution tombe en erreur.

Ce que le modèle fait, et ne fait pas

Hermes 3 tourne sur la machine elle-même, sans accès à Internet. Il ne fait que la rédaction : il résume les articles retenus, puis écrit la synthèse. Il ne les choisit pas, ne les note pas et n'écrit aucun lien — le serveur seul ajoute les liens. S'il ne répond pas, le rapport part en titres seulement.

Technologies

• Debian 13
• Python
• Flask
• SQLite
• systemd
• UFW
• Docker
• n8n
• Ollama
• Hermes 3
• pytest
• Tunnel Cloudflare

Étapes

1. Choisir les sources. 67 flux retenus, testés un par un ; 21 candidatures écartées, chacune avec son motif écrit.
2. Écrire le relevé. Téléchargement des flux, retrait des doublons, nettoyage des extraits, classement par mots-clés et note de 1 à 5.
3. Installer le serveur. Debian sans interface graphique, mise en veille désactivée, accès à distance par clé, pare-feu fermé par défaut.
4. Publier le site. Un tunnel sortant remplace l'ouverture de la box ; le site demande un mot de passe et ne dépose aucun cookie de suivi.
5. Sauvegarder. Une archive par jour, conservée 14 jours, récupérée sur une autre machine ; la procédure de remise en service est écrite.
6. Brancher le modèle. Ollama et Hermes 3 dans un conteneur sans route vers l'extérieur, n8n pour enchaîner les appels ; le serveur vérifie ensuite ce qu'il a écrit et ajoute lui-même les liens.
7. Relire le premier rapport en entier. Il a révélé quatre défauts d'extraction des articles, corrigés le matin même.

Livrables

• Le service en marche : relevé quotidien, site privé, rapport du lundi et du jeudi.
• La liste raisonnée des 67 sources et des 21 candidatures écartées avec leur motif.
• Le rapport de veille archivé et exportable, et l'export des articles lus et épinglés.
• Une installation rejouable : chaque réglage du serveur est un script versionné, relu avant d'être lancé.
• 812 tests automatisés, joués à chaque modification du code.
• La documentation du projet, en sept documents : architecture, installation, exploitation, sécurité, choix techniques, veille, oral.

Bilan

Compétences E5 visées

Gérer le patrimoine informatique · Mettre à disposition des utilisateurs un service informatique · Organiser son développement professionnel

Contexte

Au service Hardware, on me confie cette mission régulièrement depuis septembre 2025. En septembre 2026, par exemple, j'installe ESXi sur des serveurs et je configure leur RAID.

Objectifs

• Des baies de brassage réorganisées, étiquetées et documentées dans des fichiers Excel (listes de câbles).
• Des hyperviseurs VMware ESXi prêts à l'emploi : stockage en RAID, réseaux virtuels en trunk 802.1Q.
• Choix du RAID : RAID 1 pour ESXi ; RAID 5 ou RAID 10 selon le besoin : RAID 10 quand la performance et la reconstruction rapide comptent, RAID 5 quand la capacité utile prime.

Architecture

Technologies

• VMware ESXi
• RAID 1 / RAID 5 / RAID 10
• VLAN 802.1Q (trunk vers les commutateurs virtuels)
• switchs Cisco
• Excel (listes de câbles)

Étapes

1. Audit de l'existant dans les baies.
2. Câblage structuré et étiquetage.
3. Documentation dans des fichiers Excel (listes de câbles).
4. Configuration du RAID sur les serveurs HPE ProLiant (RAID 1 pour ESXi, RAID 5 ou 10 selon le besoin), puis installation d'ESXi.
5. Réseaux virtuels configurés en trunk 802.1Q.

Livrables

• Une baie câblée entièrement : plus de 150 câbles brassés.
• Baies étiquetées et documentées dans des fichiers Excel (listes de câbles).
• Hyperviseurs ESXi opérationnels.

Bilan

Compétences E5 visées

Gérer le patrimoine informatique · Mettre à disposition des utilisateurs un service informatique

Contexte

Vérifier à la main le câblage de chaque serveur, interface par interface, prend du temps et laisse passer des erreurs.

Objectifs

Démarrer les serveurs sous Debian Live par le réseau, détecter leurs interfaces réseau et vérifier qu'elles correspondent au plan de brassage.

Architecture

Serveur PXE / FOG → switch (VLAN 802.1Q) → serveurs démarrés en Debian Live par PXE.

Technologies

• PXE
• TFTP
• FOG Project
• Debian Live
• LLDP
• iPerf3
• Node.js
• export Word / PDF

Étapes

1. Déploiement de Debian Live avec FOG Project (PXE / TFTP).
2. Au démarrage, un script détecte les interfaces réseau par LLDP et vérifie qu'elles correspondent au plan de brassage.
3. J'ai développé un serveur Node.js avec une interface web : il analyse les ports des switchs et des serveurs, indique lesquels sont connectés ou non, relève les adresses MAC et les informations techniques de chaque serveur, puis produit des exports Word / PDF.

Livrables

Serveur Node.js avec son interface web ; état des ports et exports Word / PDF par serveur. Rien de tout cela n'est publié.

Bilan

Compétences E5 visées

Travailler en mode projet · Mettre à disposition des utilisateurs un service informatique

Contexte

De nouveaux postes doivent régulièrement être raccordés au réseau.

Chaque poste doit arriver sur le port qui lui est destiné : ma part est le raccordement physique, sans aucune configuration.

Objectifs

Raccorder chaque nouveau poste au port prévu par le plan, avec un câblage propre, et vérifier que le lien est actif.

Architecture

Technologies

• Câblage RJ45
• baie de brassage
• cordons de brassage
• plan de brassage

Étapes

1. Câblage RJ45 du poste.
2. Raccordement en baie de brassage.
3. Brassage vers le port du switch indiqué par le plan.
4. Vérification : le lien est actif.

Livrables

Postes raccordés chacun au port prévu, lien actif vérifié.

Compétences E5 visées

Mettre à disposition des utilisateurs un service informatique

Contexte

Des switchs Cisco doivent être remis en configuration d'usine, une tâche qui revient au fil de l'année.

Ma part est la réinitialisation, sans aucune configuration.

Objectifs

Remettre chaque switch en configuration d'usine et vérifier qu'il redémarre sans sa configuration précédente.

Architecture

Technologies

• switchs Cisco
• réinitialisation d'usine

Étapes

1. Effacement de la configuration du switch.
2. Redémarrage du switch.
3. Vérification : le switch redémarre en configuration d'usine.

Livrables

Switchs remis en configuration d'usine.

Compétences E5 visées

Gérer le patrimoine informatique

Contexte

Le matériel reçu est relevé, puis inscrit dans des fichiers Excel qui tiennent l'inventaire à jour, avant toute intégration.

Objectifs

Recenser, identifier et suivre chaque équipement : un parc tracé et un inventaire à jour dans des fichiers Excel.

Architecture

Technologies

• Excel (inventaire)
• numéros de série (S/N)
• références constructeur (P/N)

Étapes

1. Réception et tri du matériel.
2. Relevé des numéros de série (S/N), des références (P/N) et des quantités.
3. Mise à jour de l'inventaire dans les fichiers Excel.
4. Intégration du matériel une fois enregistré.

Livrables

Inventaire à jour dans des fichiers Excel.

Compétences E5 visées

Gérer le patrimoine informatique

Contexte

Quand un poste tombe en panne, un collègue me le signale ou mon tuteur me le confie. Ma mission : trouver d'où vient le problème, puis dépanner le poste.

Objectifs

Identifier la cause de chaque panne, matérielle ou système, et remettre le poste en état de marche.

Architecture

Technologies

• diagnostic de panne
• matériel du poste
• système d'exploitation

Étapes

1. Prise en charge de la demande : un collègue signale la panne, ou mon tuteur me confie le poste.
2. Observation des symptômes.
3. Recherche de la cause : matériel ou système.
4. Dépannage, une fois la cause trouvée.
5. Vérification : le poste fonctionne de nouveau.

Livrables

Postes dépannés, avec la cause de chaque panne identifiée.

Compétences E5 visées

Répondre aux incidents et aux demandes d'assistance et d'évolution