Tu veux devenir développeur en 2025 ?
Tu apprends seul, avec des tutoriels gratuits, peut-être en reconversion ?
Parfait. Ce monde t’attend à bras ouverts.
Mais attention : apprendre seul, c’est génial… mais ça peut aussi te faire prendre de mauvaises habitudes.
Et ces habitudes, elles ralentissent ton progrès, te font perdre confiance, ou pire : compromettent la sécurité de ton site.
Alors aujourd’hui, on fait le ménage. Ensemble.
Voici les 10 erreurs les plus fréquentes en développement web — et surtout, comment ne plus les faire.
1. Tu ne valides pas ce que tape l’utilisateur ? Attention, danger !
« Et si quelqu’un tapait du code malveillant dans mon formulaire ? »
— Toi, dans 2 minutes.
Imaginons : tu crées un formulaire de contact. Simple. Un champ "nom", un champ "email".
Tu penses : « C’est inoffensif. »
Mais si quelqu’un y colle ça :
<script>alert('Hacked!')</script>
… et que ton site l’affiche sans vérifier ? Boom. Tu viens de te faire pirater.
C’est ce qu’on appelle une attaque XSS (Cross-Site Scripting). Et elle arrive plus souvent qu’on ne croit.
✅ Que faire ?
- Côté navigateur : Utilise des outils comme
Validator.js pour vérifier que l’email ressemble bien à un email. - Côté serveur : Ne fais jamais confiance à l’utilisateur. Jamais.
- Utilise des requêtes préparées (comme
connection.execute() en Node.js) pour bloquer les injections SQL. - Nettoie tout : Bibliothèques comme
sanitize-html filtrent automatiquement le code dangereux.
💡 Astuce humaine :
« Si tu reçois une pomme, tu la laves. Si tu reçois une donnée, tu la valides. »
2. Ton site est lent ? Les gens s’en vont en 3 secondes
« Mon site charge en 8 secondes… c’est pas grave, non ? »
— Toi, avant de savoir que 53 % des utilisateurs partent après 3 secondes. (Source : Google)
Un site lent, c’est un site mort.
Même si ton design est magnifique, même si ton contenu est génial.
Et souvent, la faute revient à une seule image de 5 Mo en PNG, non compressée.
✅ Que faire ?
- Compresse tes images : Utilise TinyPNG ou ImageOptim .
- Passe au WebP : Format moderne, 30 % plus léger que le JPG.
- Charge à la demande : Active le
lazy loading :
- <img src="photo.webp" loading="lazy" alt="Paysage montagneux">
- Audit régulier : Ouvre Google Lighthouse → tu verras tout ce qui ralentit ton site.
🚀 Petit bonus : Un site rapide, c’est aussi mieux référencé. Deux oiseaux, une pierre.
3. Tu oublies le mobile ? Tu perds 60 % des visiteurs
« Mon site est beau sur mon écran 27 pouces. »
— Toi, avant de tester sur ton téléphone.
Statistique choc : Plus de 60 % du trafic web vient des mobiles.
Si ton site ne s’adapte pas, tu perds ton audience. Point.
Exemple : une barre de navigation fixée à 1200px ? Sur un téléphone, ça déborde. Impossible à cliquer.
✅ Que faire ?
- CSS Responsive : Utilise les
@media queries : - @media (max-width: 768px) {
- .menu { flex-direction: column; }
- }
- Frameworks simples : Bootstrap ou Tailwind CSS font le travail pour toi.
- Teste, teste, teste : Utilise les outils de développement de Chrome (F12 → "Toggle device toolbar").
📱 Astuce :
« Si ton site ne marche pas sur mobile, il ne marche pas. »
4. Tu codes sans tester ? Tu construis sur du sable
« Ça marche sur mon ordi. »
— La phrase la plus dangereuse en dev.
Imagine : ton panier d’achat permet d’ajouter un produit à -50€.
Tu ne l’as pas testé ? Surprise : quelqu’un l’exploite. Et tu perds de l’argent.
Les tests, ce n’est pas pour les pros. C’est pour éviter les catastrophes.
✅ Que faire ?
- Tests unitaires : Vérifie chaque fonction seule. Exemple avec Jest :
- test('le panier calcule bien le total', () => {
- expect(calculerTotal([10, 20])).toBe(30);
- });
- Automatise : Avec GitHub Actions, tes tests tournent à chaque modification.
- Commence petit : Teste une fonction à la fois. Tu verras, c’est addictif.
🧠 Métaphore :
« Écrire du code sans tests, c’est conduire sans ceinture. Tu peux y arriver… mais si tu freines brusquement ? »
5. Tu dis juste "Erreur" ? L’utilisateur te déteste
« Une erreur s’est produite. »
— Message le plus frustrant du web.
Et toi, en tant qu’utilisateur, tu penses quoi quand tu vois ça ?
« Merci, j’avais pas remarqué. »
Un bon message d’erreur, c’est un guide, pas une porte claquée.
✅ Que faire ?
- Sois clair :
- → Mauvais : « Erreur »
- → Bon : « Email invalide. Exemple : nom@site.com »
- Loggue tout : Utilise
Winston (Node.js) ou Monolog (PHP) pour garder trace des bugs. - Attrape les erreurs : Utilise
try/catch : - try {
- await connexionBDD();
- } catch (err) {
- logger.error("Échec de connexion", err);
- }
💬 Dialogue imaginaire :
Utilisateur : « Pourquoi ça marche pas ? »
Toi (avec logs) : « Ah, la base de données est down. Je vais réparer. »
6. Tu stockes les mots de passe en clair ? Non, vraiment ?
« Je les mets dans la base de données comme ça : motdepasse123 »
— Toi, avant d’apprendre le hachage.
Si ta base fuit (et elles fuient toutes un jour), tous les mots de passe sont visibles.
Et devine quoi ? Beaucoup de gens utilisent le même mot de passe partout.
✅ Que faire ?
- HTTPS obligatoire : Chiffre toutes les communications.
- Hachage fort : Utilise
bcrypt ou Argon2. Exemple : - const hash = await bcrypt.hash('motdepasse', 10);
- Sessions sécurisées : Utilise des cookies avec
HttpOnly et Secure.
🔐 Règle d’or :
« Si tu peux lire un mot de passe, tu n’as pas fait ton travail. »
7. Ton code est un fouillis ? Personne ne pourra t’aider
« Tout est dans src/. C’est logique, non ? »
— Toi, avant d’avoir 50 fichiers.
Un projet bien organisé, c’est un projet vivant.
Un projet en désordre, c’est un projet abandonné.
✅ Que faire ?
- Structure claire :
- /src
- /components
- /pages
- /utils
- /styles
- Nommage cohérent :
camelCase, BEM, tout ce qui t’aide à t’y retrouver. - Documente : Un petit
README.md, ça sauve des vies.
🗂️ Astuce :
« Si un collègue ne comprend pas ton code en 5 minutes, c’est qu’il faut mieux l’organiser. »
8. Tu oublies l’accessibilité ? Tu exclues 1 personne sur 7
« Mon site est beau. »
— Toi, avant de penser aux 15 % de personnes en situation de handicap.
Une image sans alt ? Invisible pour un aveugle.
Un bouton cliquable uniquement à la souris ? Inaccessible pour un paralysé.
✅ Que faire ?
- Balises sémantiques :
<button>, pas <div onclick>. - ARIA : Ajoute
aria-label="Fermer" pour les icônes. - Contraste : Utilise WebAIM Contrast Checker .
- Teste avec un lecteur d’écran : NVDA (gratuit) ou VoiceOver (Mac).
❤️ Message fort :
« Un site inclusif, c’est un site humain. »
9. Tu utilises des dépendances obsolètes ? Tu invites les hackers
« J’ai installé cette lib en 2020. Elle marche toujours ! »
— Toi, avant que npm audit te hurle dessus.
88 % des projets open-source ont au moins une dépendance vulnérable.
Et une seule peut tout compromettre.
✅ Que faire ?
npm audit : Lance-le régulièrement.- Dependabot : Active-le sur GitHub → il met à jour tes dépendances automatiquement.
- Privilégie les lib populaires : Plus de contributeurs = plus de sécurité.
🛡️ Règle simple :
« Une dépendance, c’est comme un invité chez toi. Vérifie qui entre. »
10. Tu ignores le SEO ? Ton site est invisible
« Mon site est prêt. J’attends les visiteurs. »
— Toi, avant de comprendre que Google ne lit pas dans tes pensées.
Pas de balise <h1> ? Pas de meta description ? Pas de sitemap ?
Google te pénalise. Et tu restes invisible.
✅ Que faire ?
- HTML sémantique :
- <h1>Titre principal</h1>
- <meta name="description" content="Apprendre le dev web sans se planter">
- Sitemap.xml : Liste toutes tes pages pour Google.
- Google Search Console : Gratuit, puissant, indispensable.
🔎 Astuce SEO :
« Google aime les sites clairs, rapides, et utiles. Comme les humains. »
Ahmed Oumezzine
