BUT Informatique common mistakes
BUT Informatique · Understand the traps and how to avoid them.
En algorithmique, écrire du code qui traite un cas particulier (par exemple une liste de trois éléments) sans vérifier les cas limites : liste vide, un seul élément, valeurs négatives, doublons. Le candidat rend une fonction qui « marche sur son exemple » mais échoue sur les tests cachés.
Le candidat raisonne par imitation d'exemples vus en TD plutôt que par invariants ; il ne prend pas le temps de lister les préconditions et cas dégénérés avant d'écrire la boucle ou la récursion.
What to do instead
Avant de coder, écrire en commentaire la spécification (entrées, sorties, cas limites) et construire un petit jeu de tests à la main incluant vide, singleton, doublons et bornes. Vérifier la terminaison de chaque boucle et le cas de base de chaque récursion.
En programmation orientée objet, le candidat confond héritage et composition et met tout dans une hiérarchie profonde, ou bien laisse des attributs publics modifiables de l'extérieur, sans encapsulation ni constructeur cohérent.
L'héritage est la première relation enseignée et paraît naturelle ; le candidat ne se demande pas si la relation est vraiment « est-un » et sous-estime le couplage qu'elle crée.
What to do instead
Justifier chaque relation par un test « est-un » vs « a-un » ; préférer la composition par défaut, rendre les attributs privés, exposer des accesseurs ou des méthodes métier, et vérifier que le constructeur laisse l'objet dans un état valide.
Sur les requêtes SQL, le candidat écrit une jointure qui perd ou duplique des lignes (INNER au lieu de LEFT, agrégat sans GROUP BY complet, filtre de table externe placé dans le WHERE au lieu de la condition de jointure), puis ne remarque pas que le résultat est faux.
Le candidat teste sa requête sur un jeu de données où le cas problématique n'apparaît pas (aucune ligne orpheline, aucune valeur NULL) et raisonne sur la syntaxe plutôt que sur la sémantique relationnelle.
What to do instead
Raisonner en ensembles : écrire d'abord les tables attendues, puis la jointure ; tester avec des données contenant NULL et des lignes sans correspondance ; vérifier le nombre de lignes attendu avant et après jointure ; utiliser COUNT(*) et COUNT(colonne) pour détecter les NULL.
Le candidat ne normalise pas un schéma relationnel et laisse des redondances ou des dépendances partielles, ou à l'inverse sur-normalise et multiplie les jointures sans justification, sans jamais expliquer le choix.
La normalisation est apprise comme une procédure mécanique (1FN, 2FN, 3FN) sans lien avec les anomalies réelles de mise à jour, et le candidat ne sait pas arbitrer entre intégrité et performance.
What to do instead
Pour chaque dépendance fonctionnelle identifiée, nommer l'anomalie qu'elle provoque (insertion, mise à jour, suppression) ; normaliser jusqu'à la 3FN, puis dénormaliser uniquement avec un argument de performance mesuré et documenté.
En administration système, le candidat donne des commandes sans vérifier les droits, les chemins ni l'état du service, et ne sait pas lire un journal d'erreur : il redémarre le service au lieu d'identifier la cause (port occupé, permission refusée, configuration invalide).
Le candidat a mémorisé des commandes isolées mais pas le cycle diagnostic (symptôme, hypothèse, vérification, correction) ; il saute l'étape d'observation des logs et de l'état réel du système.
What to do instead
Adopter une démarche explicite : reproduire le symptôme, lire le journal concerné, vérifier l'état (processus, port, permissions, configuration), formuler une hypothèse testable, corriger une seule variable à la fois puis revalider.
Sur les réseaux, le candidat confond les couches et attribue une fonction au mauvais niveau (par exemple dire qu'un routeur filtre selon le port TCP, ou qu'un switch attribue des adresses IP), et ne sait pas expliquer le rôle d'un masque de sous-réseau ou d'une passerelle.
Les couches sont récitées comme une liste de noms sans modèle mental du cheminement d'un paquet ; le candidat ne relie pas chaque équipement à l'unité de données qu'il traite.
What to do instead
Suivre un paquet de bout en bout sur un schéma : adresse MAC, IP, port, application ; pour chaque équipement, indiquer la couche et l'unité traitée. S'entraîner à découper un réseau en sous-réseaux et à vérifier l'appartenance d'une adresse à un préfixe.
Le candidat traite l'optimisation comme une micro-optimisation prématurée (réécrire une boucle, changer de structure) sans mesurer, ou au contraire ne sait pas analyser la complexité algorithmique d'une fonction qu'il a écrite.
Le candidat n'a pas l'habitude d'instrumenter son code ni de raisonner en ordre de grandeur ; il confond « ça a l'air rapide sur mon petit jeu de test » et complexité asymptotique.
What to do instead
Pour chaque fonction, énoncer la complexité en temps et en espace avec justification (boucles imbriquées, appels récursifs) ; mesurer avant d'optimiser avec un profilage sur une taille représentative ; comparer deux implémentations sur les mêmes données et documenter le gain.
Le candidat ne gère pas les erreurs et les ressources : fichiers ou connexions non fermés, exceptions avalées par un bloc catch vide, valeurs de retour d'erreur ignorées, absence de validation des entrées utilisateur.
Les exemples pédagogiques supposent un environnement idéal ; le candidat écrit le chemin nominal et considère la gestion d'erreur comme du code accessoire à ajouter « si le temps le permet ».
What to do instead
Lister explicitement les modes de défaillance de chaque fonction (entrée invalide, ressource indisponible, échec partiel) ; utiliser des blocs de fermeture garantie (try-with-resources, with, defer) ; ne jamais laisser un catch vide et journaliser avec contexte.
En conduite de projet, le candidat présente un planning comme une simple liste de tâches sans dépendances, sans jalons ni estimation de charge, et ne sait pas expliquer comment il réagirait à un retard ou à un changement de périmètre.
La gestion de projet est perçue comme de la documentation administrative ; le candidat n'a pas manipulé d'outil de planification ni raisonné en chemin critique et en risques.
What to do instead
Construire un planning avec tâches, durées, dépendances et jalons ; identifier le chemin critique ; associer à chaque risque majeur une mesure de mitigation ; prévoir une marge et expliquer la priorisation (MoSCoW ou équivalent) en cas de dépassement.
En travail d'équipe, le candidat décrit un projet uniquement par ses aspects techniques et ne sait pas expliquer la répartition des rôles, la gestion des versions, la revue de code ou la résolution d'un désaccord dans l'équipe.
L'évaluation porte souvent sur le livrable technique, donc le candidat néglige de préparer des exemples concrets de collaboration et de communication, alors que le référentiel attend une compétence humaine explicite.
What to do instead
Préparer des exemples vécus et datés : qui faisait quoi, comment les branches et les pull requests étaient organisées, comment un conflit ou un blocage a été traité, quel outil de suivi était utilisé. Relier chaque exemple à un comportement attendu (communication, autonomie, entraide).