En formation Administration Systèmes et Réseaux (spécialisation cybersécurité), je mets en pratique chez Awoui (LeGuideInfo) les fondamentaux du métier : infrastructure, sécurité, automatisation.
Rigoureuse et curieuse, j'aime comprendre chaque outil en profondeur avant de le documenter, pour un travail lisible et reproductible.
tiphanie@portfolio:~
$
03 / 10
Savoir-faire
Compétences & outils
Clique sur une compétence pour voir ce que j'en ai fait et les captures.
Systèmes & réseau
Linux / DebianMaîtrisé
SSH & clésMaîtrisé
VPN NetBirdMaîtrisé
nginxMaîtrisé
Conteneurs & automatisation
DockerMaîtrisé
docker-composeMaîtrisé
Git & versioningMaîtrisé
AnsibleMaîtrisé
HTML / CSSMaîtrisé
Prometheus / GrafanaMaîtrisé
04 / 10
Réalisations
Missions réalisées
Mission 01
Poste d'administration virtualisé et sécurisé, conception du portfolio professionnel
Déploiement d'un environnement de travail sous VMware Workstation (VM Debian) : mise à jour du système, authentification SSH par clés, accès au réseau privé de l'équipe via NetBird, configuration de Git, installation et vérification de nginx, puis mise en place de la chaîne d'outils (Ansible, Docker, Python) et d'un éditeur de code. Ce socle m'a permis de concevoir et publier mon portfolio : page HTML de présentation servie par un site nginx dédié sur un port personnalisé, validée par des tests curl et navigateur.
Écriture d'un Dockerfile pour empaqueter le site dans une image nginx
légère, construction et exécution du conteneur, orchestration via
docker-compose pour un démarrage reproductible en une seule commande.
Enrichissement du portfolio avec les rubriques compétences et veille
technologique.
Écriture d'un playbook Ansible décrivant l'état voulu du serveur
(nginx installé, page en place, service démarré). Validation de
l'idempotence par relances successives, et test de résilience par
suppression manuelle du contenu suivie d'une restauration automatique.
Mise en place d'un pare-feu (ufw) et des mises à jour de sécurité
automatiques, vérification de l'absence de secrets dans le dépôt,
et livraison du travail par une branche dédiée et une demande de
fusion, comme dans un vrai flux d'équipe.
Écriture d'une sonde qui teste régulièrement la disponibilité du site
et déclenche une notification push (ntfy) en cas de panne, validée par
un test réel sur une URL cassée. Mise en place d'une pile Prometheus /
Blackbox Exporter / Grafana pour visualiser l'état et l'historique de
disponibilité dans un tableau de bord dédié.
Sur le projet Eau Vive (agenda associatif fourni par le tuteur), mise en
service de l'application qui génère le flux d'agenda
(/agenda.ics), avec correction d'un blocage DNS/Docker et
validation de l'import sur un téléphone Android. À la demande du tuteur,
pivot vers une solution en JavaScript pur et à rendu statique : les
fichiers .ics sont générés à partir de la base d'événements,
versionnés sur la forge et servis par leur URL publique, la plateforme de
publication ne les servant pas directement. Livraison par branche et
demande de fusion.
La veille, c'est suivre de façon régulière et organisée ce qui évolue dans mon métier. Elle me sert à choisir les bons outils, à repérer les failles et les bonnes pratiques avant qu'elles me rattrapent, et à justifier mes choix techniques.
Je suis quelques sources fiables plutôt que « tout Internet » : par exemple les publications d'IT-Connect sur la sécurité et l'administration système.
06 / 10
Reproductibilité
Comment mon site se déploie
Le site est déployé via un playbook Ansible (deploy.yml) qui
décrit trois étapes : l'installation de nginx, la mise en place de la page
sur le serveur, et le démarrage du service.
Contrairement à un déploiement manuel, ce processus est rejouable
à l'infini sans effet de bord : relancer le playbook plusieurs fois
ne modifie rien si tout est déjà en place (idempotence). Une suppression
accidentelle de la page est automatiquement corrigée au lancement suivant,
testé et validé en conditions réelles.
1Installer nginxabsent
2Copier la page du portfolioabsent
3Démarrer le serviceabsent
Essaie : lance le playbook, relance-le, puis supprime la page et relance.
Serveur vierge. Lance le playbook pour déployer.
07 / 10
Bonnes pratiques
Sécurité
Le poste de travail est protégé par un pare-feu (ufw) refusant tout accès
entrant par défaut, avec une seule ouverture contrôlée pour l'administration à distance
par clé SSH. Le système reste à jour grâce aux mises à jour de sécurité automatiques.
Aucun secret (mot de passe, jeton, clé privée) ne transite jamais par le dépôt Git,
vérifié systématiquement dans l'historique et protégé en amont par un
.gitignore dédié. Chaque livraison passe par une branche et une
demande de fusion relue, jamais par un push direct sur main.
Voir la liste complète des mesures de sécurité
Pare-feu (ufw) : tout trafic entrant refusé par défaut, seule l'administration à distance est autorisée via un port dédié
Authentification exclusivement par clé SSH (aucun mot de passe exposé)
Accès réseau d'équipe restreint via un VPN privé (NetBird)
Mises à jour de sécurité automatiques (unattended-upgrades)
.gitignore dédié excluant tout secret (.env, clés privées, jetons)
Vérification systématique de l'historique Git (aucun secret commité)
Authentification Git par jeton d'accès personnel, jamais par mot de passe en clair
Flux de livraison en équipe : jamais de push direct sur main, toujours branche dédiée puis Pull Request relue
Déploiements idempotents (Ansible) : pas de dérive de configuration incontrôlée
Supervision continue avec alerte immédiate en cas d'anomalie
08 / 10
Vigilance continue
Supervision
Une sonde (sonde.sh) vérifie chaque minute que le site répond, et
déclenche une notification push en cas de panne — testé pour de vrai sur une
URL cassée, avant de revenir à la normale.
Une pile Prometheus, Blackbox Exporter et Grafana sonde l'URL publique et
affiche son état ainsi que son historique de disponibilité dans un tableau
de bord dédié.
Tableau de bord Grafana — probe_success à 1 (site en ligne)
Vérifié le 18/09/2026 à 07h49
Alerte ntfy reçue lors du test de panne
Testé le 18/09/2026 à 07h43
09 / 10
Projet associatif
Pont iCal — Agenda Eau Vive En cours
Une église évangélique (Eau Vive) a fourni une copie figée de son site d'agenda,
dont le bouton « S'abonner à l'agenda » ne fonctionnait pas. L'objectif : retrouver
le flux d'agenda réel et documenter comment un utilisateur Android peut s'y abonner
depuis Google Agenda.
Étape 1 — Récupérer le projet du tuteur
Clonage du dépôt du tuteur, deux remotes configurés (upstream vers
l'original, origin vers mon espace), intégration en sous-dossier de
mon dépôt Stage_2026 existant, clé d'accès personnelle pour Git, puis
nettoyage des dossiers de test et sous-modules fantômes accumulés pendant les essais.
Blocage : le fork automatique était désactivé
par le tuteur (copie faite manuellement) et la création d'un dépôt séparé était
refusée aux comptes élèves (intégré en sous-dossier à la place).
Étape 2 — Retrouver le flux de l'agenda
Repérage de l'adresse attendue (/agenda.ics) dans le code du site figé,
puis recherche sur la machine de travail de l'application réelle capable de générer
ce flux à la demande. Trouvée dans un dossier séparé, avec deux services à lancer
(événements + site web) sur le port 8211.
Blocage : l'adresse du flux dans la copie
figée était neutralisée puisque cette copie n'est qu'une photographie sans
fonctionnalités actives — la vraie application se trouvait ailleurs sur la machine.
Étape 3 — Rendre l'application accessible sur le réseau
Passage de la carte réseau de la VM du mode NAT (isolé) au mode Pont (Bridged), pour
obtenir une adresse réseau à part entière sur le Wi-Fi, joignable depuis un autre appareil.
Blocage : le réseau pont n'existait pas encore
côté logiciel de virtualisation — recréé manuellement puis rattaché explicitement à la
bonne carte Wi-Fi.
Étape 4 — Construire et démarrer l'application
Lancement de la commande de build/démarrage des deux services Docker.
Blocage : le DNS de la machine passait par un
VPN injoignable depuis les conteneurs — corrigé en forçant Docker à utiliser des DNS
publics (8.8.8.8, 1.1.1.1) via /etc/docker/daemon.json.
Étape 5 — Vérifier que le flux d'agenda fonctionne
Page d'accueil testée dans le navigateur (deux événements réels affichés), puis
/agenda.ics testé directement : fichier iCalendar valide contenant trois
événements (soirée jeux, atelier vélo, assemblée générale) correctement structuré.
Étape 6 — Tester l'import sur un téléphone Android
Téléchargement du flux depuis l'adresse locale de la VM, puis import réel depuis un
téléphone Android connecté au même Wi-Fi : le fichier .ics est reconnu et
ouvert par l'application Calendrier, avec les trois événements affichés correctement.
Test réel — l'import ponctuel est validé de A à Z, y compris visuellement.
Prochaine étape
L'import fonctionne pour l'instant en local, une fois à la demande. Pour qu'il devienne
un abonnement automatique dans Google Agenda, le flux devra être accessible depuis
l'extérieur du réseau local — c'est l'objet du travail en cours.
10 / 13
Me contacter
Travaillons ensemble
Vous recherchez un profil junior en administration systèmes, réseaux ou cybersécurité ? Vous l'avez trouvé.
Curieuse, rigoureuse et motivée à approfondir l'administration systèmes, réseaux et sécurité, je suis ouverte à toute opportunité ou échange professionnel.