Alex Jovéniaux

02 — Portfolio

Compétences & apprentissages critiques

Démarche réflexive sur mes apprentissages au sein du BUT Réseaux & Télécommunications, structurée selon les trois compétences cœur du référentiel : Administrer, Connecter, Programmer. Pour chaque apprentissage critique (AC) de niveau 1, je mets en avant les projets associés et un retour d'expérience.

Compétence 1

Administrer les réseaux et l'Internet

Niveau 1 — Assister l'administrateur du réseau

AC11.01 Maîtriser les lois fondamentales de l'électricité afin d'intervenir sur des équipements de réseaux et télécommunications +

Projets / ressources associés

Ce que j'ai fait

Étude des lois fondamentales de l'électricité en régime continu : courant et tension, loi d'Ohm, lois de Kirchhoff (loi des mailles et loi des nœuds) et associations de récepteurs et de générateurs en série et en parallèle.

Pourquoi je l'ai fait

Ces lois sont la base pour comprendre l'alimentation et le fonctionnement des équipements de réseaux et de télécommunications, et pour intervenir dessus sans risque.

Comment je l'ai fait

Cours et exercices en régime continu : analyse de circuits, application de la loi des mailles et de la loi des nœuds, et calcul des tensions et des courants sur des montages simples.

Mes difficultés

Choisir correctement le sens conventionnel du courant et appliquer rigoureusement la loi des mailles (signes des tensions) m'a demandé de la rigueur : une simple erreur de signe faussait tout le calcul.

Ce que j'en ai appris

Un circuit, même complexe, se ramène à l'application méthodique de quelques lois ; poser proprement le schéma et les conventions de signe évite la plupart des erreurs.

Ce que je ferais autrement

Je recouperais systématiquement mes résultats avec la loi des nœuds (somme des courants) en plus de la loi des mailles, pour vérifier mes calculs.

AC11.02 Comprendre l'architecture et les fondements des systèmes numériques, les principes du codage de l'information, des communications et de l'Internet +

Projets / ressources associés

Ce que j'ai fait

Étude des protocoles ARP, ICMP, DNS, DHCP, TCP/UDP, ainsi que de l'adressage IPv4/IPv6 et du codage de l'information dans les trames Ethernet. Mise en pratique via captures Wireshark et analyse de plans d'adressage.

Pourquoi je l'ai fait

Maîtriser les fondements d'Internet est indispensable avant de configurer ou d'administrer un réseau : sans cette base, le dépannage et la conception sont impossibles.

Comment je l'ai fait

Cours magistraux, TD d'adressage, TP Cisco Packet Tracer puis matériel réel, captures Wireshark et préparation à la certification CCNA SRWE.

Mes difficultés

Le subnetting en notation CIDR m'a demandé beaucoup d'entraînement, en particulier le calcul rapide de masques et de plages d'adresses sans calculatrice. L'enchaînement des en-têtes (Ethernet → IP → TCP) dans une capture Wireshark m'a aussi paru dense au départ.

Ce que j'en ai appris

Une compréhension de bout en bout du voyage d'un paquet, depuis la couche physique jusqu'à l'application. Lire une capture Wireshark me permet désormais d'identifier rapidement un dysfonctionnement.

Ce que je ferais autrement

Je m'entraînerais au subnetting dès le début avec des exercices quotidiens plutôt que de réviser dans l'urgence, et j'utiliserais davantage les filtres d'affichage Wireshark pour isoler un protocole à la fois.

AC11.03 Configurer les fonctions de base du réseau local +

Projets / ressources associés

Ce que j'ai fait

Configuration de commutateurs Cisco 2960 : VLANs, liens trunk multi-VLAN (802.1Q), STP/RSTP, EtherChannel, et routage inter-VLAN sur routeur Cisco série 800. Déploiement testé sur Packet Tracer puis sur matériel réel lors de la SAÉ 1.02.

Pourquoi je l'ai fait

Segmenter un réseau d'entreprise (Admin, Personnel, Production, Vidéo) est la première brique de la sécurité et de la performance LAN.

Comment je l'ai fait

Plan d'adressage IPv4 préparé sur draw.io, simulation Packet Tracer pour validation, puis configuration en CLI Cisco IOS sur l'équipement réel encadrée par les RT2.

Mes difficultés

J'ai mis du temps à bien distinguer les modes access et trunk, et j'ai provoqué une coupure réseau due à une boucle avant la convergence du STP. J'avais aussi oublié de sauvegarder une configuration avec write memory, ce qui m'a tout fait reperdre après un redémarrage.

Ce que j'en ai appris

L'importance de documenter et de tester chaque étape avant de passer à la suivante. Le passage de la simulation au matériel réel révèle toujours des subtilités (timing STP, négociation DTP…).

Ce que je ferais autrement

Je sauvegarderais la configuration après chaque étape validée et je documenterais le rôle de chaque port (access/trunk + VLAN) dans un tableau avant de configurer, pour éviter les erreurs de mode.

AC11.04 Maîtriser les rôles et les principes fondamentaux des systèmes d'exploitation afin d'interagir avec ceux-ci pour la configuration et l'administration des réseaux et services fournis +

Projets / ressources associés

Ce que j'ai fait

Déploiement et configuration de serveurs Linux (Debian/Ubuntu) : services dnsmasq (DHCP+DNS), serveur web Apache2, passerelle Linux avec IP forwarding et NAT via iptables. Gestion via CLI et fichiers de configuration.

Pourquoi je l'ai fait

La majorité des serveurs et équipements réseau s'administrent via un système Unix-like. Savoir manipuler Linux en CLI est une compétence pivot.

Comment je l'ai fait

VirtualBox pour le banc de test, manipulation systemd, lecture/modification de fichiers de conf, vérification systématique avec systemctl status et logs journalctl.

Mes difficultés

La syntaxe des fichiers de configuration (dnsmasq, Apache) est stricte : un point-virgule ou une accolade oubliés faisaient échouer le service sans message évident. Comprendre pourquoi un service refusait de démarrer via journalctl m'a demandé de l'habitude.

Ce que j'en ai appris

L'autonomie sur la ligne de commande Linux est un multiplicateur de productivité. Comprendre où chercher (logs, conf, processus) accélère énormément le diagnostic.

Ce que je ferais autrement

Je validerais chaque modification avec un test de configuration (par ex. apache2ctl configtest) et un systemctl status avant de passer à la suite, au lieu de cumuler plusieurs changements puis de chercher l'erreur.

AC11.05 Identifier les dysfonctionnements du réseau local et savoir les signaler +

Projets / ressources associés

Ce que j'ai fait

Diagnostic réseau via ping, traceroute, arp -a, captures Wireshark pour valider ARP/DNS/DHCP, vérification du routage inter-VLAN et de la stabilité globale du réseau.

Pourquoi je l'ai fait

Tout déploiement provoque des incidents : savoir où regarder permet de remonter à la cause racine plutôt que de bricoler des contournements.

Comment je l'ai fait

Méthode descendante (couche application → physique) ou ascendante selon les symptômes. Documentation systématique des tests et résultats dans des notebooks Jupyter avec Markdown.

Mes difficultés

Ma tendance était de modifier plusieurs paramètres en même temps quand quelque chose ne fonctionnait pas, ce qui rendait impossible d'identifier la vraie cause. Isoler un symptôme avant d'agir n'était pas encore un réflexe.

Ce que j'en ai appris

Une démarche méthodique de troubleshooting et l'importance d'écrire un compte-rendu clair pour un collègue ou un N+2.

Ce que je ferais autrement

J'appliquerais une démarche couche par couche stricte (ping → table ARP → routage → service) et je ne changerais qu'un paramètre à la fois en notant l'effet de chaque test.

AC11.06 Installer un poste client, expliquer la procédure mise en place +

Projets / ressources associés

Ce que j'ai fait

Installation et configuration de postes clients (machines virtuelles Linux) raccordés aux différents VLANs, attribution DHCP, vérification de la résolution DNS et de l'accès aux services internes (web Apache).

Pourquoi je l'ai fait

Un réseau n'a de valeur que s'il sert les utilisateurs. Le poste client valide l'ensemble de la chaîne réseau.

Comment je l'ai fait

VirtualBox, profils réseau pontés sur les VLANs, tests de connectivité couche par couche, documentation de la procédure pas-à-pas.

Mes difficultés

Le rattachement des machines virtuelles au bon VLAN via les profils réseau de VirtualBox m'a posé problème : une carte mal configurée et le poste n'obtenait pas d'adresse DHCP. La résolution DNS ne fonctionnait pas tant que la passerelle n'était pas correcte.

Ce que j'en ai appris

L'importance d'une procédure reproductible : un poste client doit pouvoir être réinstallé à l'identique sans dépendre de la mémoire de l'opérateur.

Ce que je ferais autrement

Je préparerais une VM modèle clonable et une check-list de validation (adresse DHCP, ping passerelle, résolution DNS, accès web) pour rendre l'installation reproductible et plus rapide.

Compétence 2

Connecter les entreprises et les usagers

Niveau 1 — Découvrir les transmissions et la ToIP

AC12.01 Mesurer, analyser et commenter les signaux +

Projets / ressources associés

Ce que j'ai fait

Mesures et caractérisation de signaux sur câbles Ethernet et coaxiaux : analyse d'atténuation, mesure du retard, et confrontation théorie/simulation.

Pourquoi je l'ai fait

Comprendre comment un signal se dégrade sur un support physique est indispensable pour dimensionner correctement une infrastructure.

Comment je l'ai fait

Calcul théorique, simulation LTspice et préparation de mesures réelles. Présentation des résultats sous forme de courbes commentées.

Mes difficultés

Faire le lien entre la valeur d'atténuation calculée et ce que je lisais sur la courbe simulée n'était pas évident, notamment à cause des unités (dB, dB/m) et des échelles logarithmiques.

Ce que j'en ai appris

Un signal numérique reste une grandeur analogique : impédance, longueur de câble et fréquence influencent directement la fiabilité.

Ce que je ferais autrement

Je poserais clairement les unités et l'échelle avant toute mesure, et je comparerais systématiquement un câble court et un câble long pour visualiser l'effet plutôt que de raisonner sur une seule valeur.

AC12.02 Caractériser des systèmes de transmissions élémentaires et découvrir la modélisation mathématique de leur fonctionnement +

Projets / ressources associés

Ce que j'ai fait

Modélisation mathématique d'un câble : calcul d'atténuation, de retard de propagation, et confrontation aux courbes simulées sous LTspice et MATLAB.

Pourquoi je l'ai fait

Mettre une équation derrière un phénomène permet de prédire le comportement d'un système et de dimensionner les marges.

Comment je l'ai fait

Cours de mathématiques pour la transmission, TP MATLAB pour la simulation et TD pour la mise en équation.

Mes difficultés

Passer de l'équation théorique à sa mise en œuvre sous MATLAB demandait de bien comprendre chaque paramètre du modèle ; une erreur de coefficient donnait une courbe sans rapport avec la mesure.

Ce que j'en ai appris

Une approche scientifique : modèle, mesure, écart au modèle, justification de l'écart.

Ce que je ferais autrement

Je vérifierais le modèle sur un cas simple dont je connais le résultat à la main avant de l'appliquer au cas complet, pour valider l'implémentation étape par étape.

AC12.03 Déployer des supports de transmission +

Projets / ressources associés

TP brassage cuivre / fibre optique

Ce que j'ai fait

Mise en œuvre concrète de câbles Ethernet et coaxiaux : repérage des supports, contraintes mécaniques et électriques, et tests de continuité.

Pourquoi je l'ai fait

Une grande partie des incidents réseau provient de la couche physique. Savoir déployer correctement un support évite une catégorie entière de pannes.

Comment je l'ai fait

TP encadrés en laboratoire avec mesures contradictoires entre câbles courts et longs.

Mes difficultés

Le sertissage et le respect de l'ordre des paires (norme T568) demandent de la minutie : mes premiers câbles ne passaient pas le test de continuité. Distinguer l'effet d'un câble court de celui d'un câble long n'était pas intuitif.

Ce que j'en ai appris

La qualité d'un câblage se mesure : il ne suffit pas que « ça passe », il faut que ça passe avec marge.

Ce que je ferais autrement

Je testerais chaque câble au testeur de continuité immédiatement après le sertissage plutôt qu'à la fin, pour repérer tout de suite l'erreur de câblage.

AC12.04 Connecter les systèmes de ToIP +

Projets / ressources associés

Ce que j'ai fait

Mise en place d'un serveur de téléphonie sur IP avec Asterisk : configuration de l'IPBX, déclaration de comptes SIP et raccordement de postes téléphoniques IP physiques ainsi que de softphones, pour établir des appels internes.

Pourquoi je l'ai fait

La voix sur IP est aujourd'hui intégrée aux réseaux d'entreprise ; comprendre comment un appel transite sur le même réseau que les données est essentiel pour un futur technicien R&T.

Comment je l'ai fait

Installation et configuration d'Asterisk sous Linux (comptes et plan de numérotation), enregistrement des postes en SIP, puis tests d'appels entre postes IP et softphones.

Mes difficultés

La syntaxe des fichiers de configuration d'Asterisk (contextes, extensions) n'est pas évidente, et un poste qui refusait de s'enregistrer en SIP m'obligeait à vérifier méthodiquement le compte, le mot de passe et la configuration réseau du poste.

Ce que j'en ai appris

La ToIP réutilise directement l'adressage et les VLAN du réseau de données : un appel n'est qu'un flux qui dépend entièrement de la bonne configuration réseau sous-jacente.

Ce que je ferais autrement

Je capturerais un appel sous Wireshark pour observer concrètement la signalisation SIP et le flux RTP, et je mettrais en place une qualité de service (priorisation de la voix) sur un VLAN voix dédié.

AC12.05 Communiquer avec un tiers (client, collaborateur...) et adapter son discours et sa langue à son interlocuteur +

Projets / ressources associés

Anglais professionnel (C1)

Ce que j'ai fait

Collaboration en équipe lors de la SAÉ 1.02 avec partage de tâches, rédaction de documentation technique en Markdown et présentation orale du projet. Pratique régulière de l'anglais technique en cours et lors de la lecture des datasheets Cisco.

Pourquoi je l'ai fait

Un technicien R&T ne travaille jamais seul ; vulgariser et adapter son langage est aussi important que la maîtrise technique.

Comment je l'ai fait

Discord/Teams pour la coordination interne, rédaction de comptes-rendus précis, soutenance orale.

Mes difficultés

Lors de la SAÉ 1.02, répartir clairement les tâches et faire converger les comptes-rendus de chacun a été plus difficile que la partie technique elle-même. À l'oral, j'avais tendance à entrer trop vite dans les détails pour un auditoire non spécialiste.

Ce que j'en ai appris

Un schéma clair et un vocabulaire ajusté valent souvent mieux qu'un long discours technique.

Ce que je ferais autrement

Je fixerais dès le départ une trame commune de documentation pour le groupe, et je construirais ma présentation en partant du schéma global avant d'entrer dans les détails techniques.

Compétence 3

Créer des outils et applications informatiques pour les R&T

Niveau 1 — S'intégrer dans un service informatique

AC13.01 Utiliser un système informatique et ses outils +

Projets / ressources associés

Ce que j'ai fait

Manipulation quotidienne de Linux (Debian/Ubuntu) en ligne de commande, gestion de versions avec git, utilisation de Jupyter Notebook pour la documentation et de VirtualBox pour le banc d'essai.

Pourquoi je l'ai fait

Tous les projets R&T (académiques ou personnels) reposent sur cet écosystème d'outils. Le maîtriser est un prérequis.

Comment je l'ai fait

Apprentissage par la pratique, recherche systématique dans la documentation officielle et reproduction d'exemples avant adaptation.

Mes difficultés

Mémoriser les commandes Linux et les options de git m'a demandé de la répétition ; au début je perdais du temps à chercher la bonne commande. La résolution d'un conflit git m'a aussi déstabilisé la première fois.

Ce que j'en ai appris

L'écosystème CLI/git/Linux est cohérent : une compétence sur un outil renforce toutes les autres.

Ce que je ferais autrement

Je me constituerais un mémo personnel des commandes et manipulations git fréquentes, et je m'entraînerais à résoudre des conflits sur un dépôt de test plutôt qu'en situation réelle.

AC13.02 Lire, exécuter, corriger et modifier un programme +

Projets / ressources associés

Ce que j'ai fait

Lecture de codes existants (bibliothèques React, Real-ESRGAN), debug pas-à-pas, modification de comportements et écriture de petits scripts d'automatisation Python.

Pourquoi je l'ai fait

Comprendre du code écrit par d'autres est la première étape avant d'en écrire soi-même de manière professionnelle.

Comment je l'ai fait

Lecture commentée, debugger intégré à VSCode, points d'arrêt et inspection de la pile.

Mes difficultés

Comprendre du code écrit par d'autres (composants React, code de Real-ESRGAN) avant de pouvoir le modifier était intimidant : je ne savais pas par où commencer pour suivre le fil d'exécution.

Ce que j'en ai appris

La majorité du temps d'un développeur se passe à lire et comprendre, pas à écrire. La lisibilité du code est une compétence à part entière.

Ce que je ferais autrement

J'utiliserais plus tôt le débogueur pas-à-pas avec des points d'arrêt pour suivre concrètement l'exécution, plutôt que de relire tout le code en essayant de le comprendre d'un bloc.

AC13.03 Traduire un algorithme, dans un langage et pour un environnement donné +

Projets / ressources associés

Ce que j'ai fait

Implémentation de Dijkstra et A* sur grille (JavaScript / React) ainsi que de plusieurs algorithmes de tri (Bubble, Selection, Insertion, Quick) avec visualisation pas-à-pas.

Pourquoi je l'ai fait

Traduire un algorithme abstrait en code fonctionnel est l'exercice central de la programmation.

Comment je l'ai fait

Pseudo-code papier → implémentation incrémentale → tests visuels via animations.

Mes difficultés

L'implémentation de la file de priorité pour A* et la gestion des états intermédiaires d'animation (sans figer l'interface) m'ont demandé plusieurs essais avant d'obtenir un résultat correct.

Ce que j'en ai appris

Visualiser un algorithme aide énormément à le comprendre — et à le déboguer.

Ce que je ferais autrement

Je validerais d'abord l'algorithme sur de petites données avec de simples affichages textuels avant d'ajouter la couche d'animation, pour bien séparer la logique de la visualisation.

AC13.04 Connaître l'architecture et les technologies d'un site Web +

Projets / ressources associés

Ce que j'ai fait

Conception du présent portfolio en HTML5/CSS3/JavaScript vanilla et de plusieurs applications React (Vite + Tailwind). Mise en place d'animations canvas et d'une visualisation 3D Three.js.

Pourquoi je l'ai fait

Le web est le support naturel pour rendre un travail accessible et démontrable, en stage comme en alternance.

Comment je l'ai fait

Maquette → maquette HTML → CSS → JS interactif. Déploiement via GitHub Pages et Vercel.

Mes difficultés

Le responsive m'a donné du fil à retordre, en particulier l'adaptation du menu et des grilles sur petit écran. Sur les projets React, la gestion de l'état partagé entre composants n'était pas évidente au départ.

Ce que j'en ai appris

L'écart entre « ça marche sur mon poste » et « c'est en ligne accessible à tous » est une vraie marche à franchir, qui passe par la CI/CD et l'hébergement.

Ce que je ferais autrement

Je concevrais en mobile-first dès le départ plutôt que d'adapter un design pensé pour le bureau, et je testerais sur plusieurs tailles d'écran tout au long du développement.

AC13.05 Choisir les mécanismes de gestion de données adaptés au développement de l'outil et argumenter ses choix +

Projets / ressources associés

Ce que j'ai fait

Choix du format de données selon le besoin : TLE/JSON pour Orbital Tracker, fichiers de zone dnsmasq pour SAÉ 1.02, état mémoire pour les visualizers.

Pourquoi je l'ai fait

Le format des données contraint l'architecture entière : il faut le choisir tôt et le justifier.

Comment je l'ai fait

Comparaison rapide des formats candidats (lecture humaine, taille, support natif du langage) avant décision.

Mes difficultés

Choisir le bon format sans recul n'était pas évident : pour Orbital Tracker, le parsing des données TLE et leur mise à jour régulière depuis l'API Celestrak m'ont demandé de comprendre précisément la structure du format.

Ce que j'en ai appris

Une bonne structure de données simplifie le code ; une mauvaise complique tout en aval.

Ce que je ferais autrement

Je documenterais dès le départ le schéma des données et leurs contraintes (taille, fréquence de mise à jour) avant d'écrire le code qui les consomme.

AC13.06 S'intégrer dans un environnement propice au développement et au travail collaboratif +

Projets / ressources associés

GitHub — alex-jov

Ce que j'ai fait

Utilisation systématique de git et GitHub pour tous mes projets (académiques et personnels), avec une organisation par branches et des commits réguliers et documentés.

Pourquoi je l'ai fait

Le travail collaboratif est la norme dans l'industrie. Git est l'outil standard et incontournable.

Comment je l'ai fait

VSCode + extensions git, conventions de nommage des commits, README détaillé pour chaque dépôt public.

Mes difficultés

Adopter une organisation de branches claire et des messages de commit utiles m'a demandé de la discipline ; mes premiers dépôts avaient un historique brouillon. Travailler à plusieurs sur un même dépôt m'a fait découvrir l'importance des conflits et des règles communes.

Ce que j'en ai appris

Un dépôt git propre et bien organisé est une carte de visite : il rassure autant qu'un CV.

Ce que je ferais autrement

Je définirais une convention de nommage des commits et des branches dès le premier commit, et je ferais des commits plus petits et plus fréquents pour faciliter la relecture.