BUT Réseaux et Télécommunications common mistakes
BUT Réseaux et Télécommunications · Understand the traps and how to avoid them.
Lors d'un exercice de subnetting, le candidat calcule le nombre de sous-réseaux et d'hôtes sans soustraire l'adresse de réseau et l'adresse de diffusion, ou oublie de convertir correctement le masque CIDR en notation décimale pointée.
Le candidat applique mécaniquement des formules (2^n) sans se demander si le contexte exige des sous-réseaux utilisables, et il confond le nombre total d'adresses avec le nombre d'hôtes disponibles. La pression du temps le pousse à sauter la vérification de la conversion binaire-décimal.
What to do instead
Pour chaque question de subnetting, écrire systématiquement : (1) le masque en binaire, (2) le nombre de bits empruntés, (3) le nombre de sous-réseaux = 2^n (ou 2^n-2 si l'énoncé précise 'utilisables'), (4) le nombre d'hôtes = 2^m-2. Vérifier ensuite avec un exemple concret (première et dernière adresse de la plage). S'entraîner à convertir le masque CIDR en décimale pointée sans calculatrice.
Le candidat décrit le fonctionnement d'un protocole (TCP, ARP, DHCP, etc.) en termes vagues sans citer les champs d'en-tête, les numéros de port, ni l'ordre exact des échanges (handshake, découverte, etc.).
Le candidat a mémorisé des notions générales mais n'a pas structuré ses connaissances au niveau des détails protocolaires. Il pense qu'une réponse 'à peu près' suffit, alors que le correcteur attend des éléments précis et hiérarchisés.
What to do instead
Pour chaque protocole au programme, préparer une fiche avec : le rôle, l'en-tête (champs et tailles), les ports par défaut, et la séquence temporelle des messages (ex : SYN, SYN-ACK, ACK pour TCP ; DHCPDISCOVER, OFFER, REQUEST, ACK). En examen, répondre en listant explicitement ces éléments, même sous forme de puces.
En administration réseau, le candidat propose une configuration (VLAN, routage, ACL) sans vérifier la cohérence avec le plan d'adressage existant, ou sans tester la connectivité de bout en bout.
Le candidat se concentre sur la commande à taper et néglige l'impact sur l'ensemble du réseau. Il ne prend pas le temps de relire l'énoncé pour identifier les contraintes (adresses déjà utilisées, passerelles, etc.).
What to do instead
Adopter une méthode en trois étapes : (1) reformuler les contraintes de l'énoncé sur un brouillon (adresses, VLAN, équipements), (2) vérifier que la proposition respecte ces contraintes (pas de chevauchement, masque cohérent), (3) simuler mentalement un ping de bout en bout en listant les tables de routage et les ACL traversées. Si possible, utiliser un simulateur (Packet Tracer, GNS3) pour valider.
Le candidat rédige une règle de pare-feu ou une ACL en mélangeant les sens (entrant/sortant) et l'ordre des règles, ou oublie le 'deny all' implicite à la fin.
La notion de flux directionnel et de première correspondance est mal assimilée. Le candidat raisonne en termes d'équipements plutôt que de flux (source, destination, protocole, port).
What to do instead
Toujours écrire les règles sous la forme : 'autoriser/refuser le flux de [source] vers [destination] sur le port [X]'. Placer les règles les plus spécifiques en premier. Terminer explicitement par un refus de tout le reste. Vérifier ensuite avec un exemple de paquet concret en suivant l'ordre des règles.
Lors d'un exercice de développement, le candidat écrit un algorithme ou un extrait de code sans gérer les cas d'erreur (entrées invalides, division par zéro, fichiers absents) ni les exceptions.
Le candidat se focalise sur le cas nominal et sous-estime l'importance de la robustesse, souvent par manque d'expérience des tests ou par volonté d'aller vite.
What to do instead
Systématiquement, après avoir écrit la logique principale, ajouter : la validation des entrées (types, plages), la gestion des exceptions avec un message clair, et un jeu de tests incluant des cas limites (0, null, chaîne vide, très grande valeur). En examen, mentionner explicitement ces vérifications dans la réponse.
Le candidat utilise des requêtes SQL ou des appels réseau sans se soucier de la sécurité (injection SQL, absence d'échappement, mots de passe en clair) dans une réponse à un problème d'intégration.
Le candidat privilégie la fonctionnalité à la sécurité, ou ne connaît pas les bonnes pratiques de développement sécurisé. Il reproduit des schémas appris sans esprit critique.
What to do instead
Intégrer les réflexes : requêtes paramétrées, validation côté serveur, chiffrement des mots de passe (hachage salé), HTTPS. En examen, si l'on présente un extrait de code, ajouter une phrase justifiant les choix de sécurité. S'entraîner à repérer les failles dans des extraits fournis.
Le candidat rend une copie de communication professionnelle (email, note de synthèse) sans adaptateur ni destinataire clairement identifié, avec un objet absent ou trop vague, et un registre inadapté.
Le candidat transpose ses habitudes de messagerie personnelle (style relâché, absence d'objet) dans un contexte professionnel, ou néglige les codes de la communication écrite.
What to do instead
Utiliser une trame fixe : objet explicite (contexte + action attendue), formule d'appel, paragraphes courts avec un idée par paragraphe, formule de politesse, signature avec fonction. Relire en se demandant : 'le destinataire sait-il qui je suis, ce que je veux, et ce qu'il doit faire ?'
Lors d'une soutenance ou d'un oral, le candidat lit ses notes mot à mot, ne regarde pas le jury, et dépasse le temps imparti sans gérer son plan.
Le stress et le manque d'entraînement à l'oral poussent à se rassurer par la lecture. Le candidat n'a pas chronométré sa présentation ni répété devant un tiers.
What to do instead
Préparer des notes sous forme de mots-clés (pas de phrases), répéter au moins deux fois à voix haute en chronométrant. Prévoir une marge de 10% sur le temps. S'entraîner à regarder le jury en balayant du regard. Si l'on perd le fil, utiliser une phrase de transition préparée.
Le candidat, face à un problème technique complexe, se lance immédiatement dans une solution sans reformuler le besoin ni proposer d'étapes de diagnostic, et rend une réponse unique sans alternative.
Le candidat veut montrer qu'il 'sait faire' et craint de perdre du temps. Il confond rapidité et efficacité, et ne structure pas sa démarche.
What to do instead
Appliquer la méthode : (1) reformuler le problème en une phrase, (2) lister les hypothèses et les informations manquantes, (3) proposer une démarche de diagnostic étape par étape, (4) envisager une solution principale et une alternative. Même si la solution finale est simple, montrer cette structuration rapporte des points.
Le candidat traite chaque question de manière isolée sans faire de lien avec les autres domaines (par exemple, il propose une architecture réseau sans penser aux aspects sécurité ou développement), et ne relit pas sa copie pour vérifier la cohérence globale.
La préparation est souvent cloisonnée par matière, et le candidat ne s'entraîne pas à des sujets transversaux. En examen, la gestion du temps l'empêche de prendre du recul.
What to do instead
S'entraîner sur des sujets transversaux (ex : 'concevoir une solution complète pour une PME' intégrant réseau, sécurité, application). En examen, réserver les 5 dernières minutes pour une relecture ciblée : vérifier que chaque réponse technique mentionne les impacts sécurité et les aspects opérationnels, et que les réponses aux questions de communication sont cohérentes avec le reste.