5 erreurs de développeurs juniors qui tuent votre site internet

Recourir à un développeur junior pour faire son site web peut être économique. Mais sans encadrement par un senior, les erreurs récurrentes finissent par coûter bien plus cher en maintenance et en opportunités SEO ratées. Voici les 5 erreurs qu’on retrouve sur 80 % des sites livrés par des juniors mal accompagnés.

1. Pas de validation des entrées utilisateur

C’est l’erreur n°1 et la plus dangereuse.

Le symptôme

Un formulaire de contact qui accepte tout et n’importe quoi : champs vides, emails invalides, payloads de plusieurs Mo, caractères de contrôle dans les noms.

Pourquoi c’est grave

Les conséquences vont du plus bénin au plus grave :

• Spam : votre boîte mail saturée par des bots
• Email injection : un attaquant insère \nBcc: spam@example.com dans le champ « nom » → votre serveur SMTP devient relais de spam
• XSS stockée : si un commentaire contient <script>...</script> et est affiché tel quel, c’est une faille de sécurité
• DoS applicatif : 1 000 requêtes simultanées avec des payloads énormes plombent le serveur

La solution

• Côté client : validation HTML5 (required, type="email", maxlength)
• Côté serveur : validation systématique avec Zod ou Valibot en TypeScript
• Sanitization : strip des caractères de contrôle, échappement HTML
• Rate limiting : pas plus de 5 requêtes/min/IP par défaut
• Honeypot anti-bot : champ caché qui piège les bots

OWASP Cheat Sheet sur la validation des entrées — le standard du domaine.

2. Stocker les secrets en dur dans le code

Le symptôme

// Dans le fichier source
const STRIPE_SECRET = "sk_live_aBcDeF1234567890..."; // 🚨 RED FLAG
const SMTP_PASSWORD = "MotDePasseSuper2024!"; // 🚨 RED FLAG

Pourquoi c’est grave

Si le code est versionné sur Git (même privé), les secrets se retrouvent dans l’historique. Un développeur qui clone le repo voit les secrets. Si le repo devient public par erreur, c’est l’enfer (clés API utilisées par des inconnus, factures Stripe astronomiques, etc.).

La solution

• Variables d’environnement : dans un fichier .env (gitignored) ou via le système d’exploitation
• Gestionnaire de secrets : 1Password Connect, AWS Secrets Manager, Vault pour les projets sérieux
• Convention .env.example : un fichier exemple commité, sans les vraies valeurs

// Bonne pratique
const STRIPE_SECRET = process.env.STRIPE_SECRET_KEY;
if (!STRIPE_SECRET) throw new Error("STRIPE_SECRET_KEY manquant");

3. Pas de gestion d’erreur

Le symptôme

async function envoyerEmail(data) {
  await transporter.sendMail(data); // Si ça plante, l'utilisateur voit un écran blanc
  return { success: true };
}

Pourquoi c’est grave

• Mauvaise UX : l’utilisateur ne sait pas si son action a réussi
• Logs inutiles : impossible de debug en prod
• Écrans blancs sur erreur : l’utilisateur quitte le site
• Failles de sécurité potentielles : un crash mal géré peut leak des infos sensibles dans les messages d’erreur

La solution

• Try/catch systématique sur les appels asynchrones
• Messages d’erreur user-friendly (« une erreur est survenue, réessayez ou contactez-nous »)
• Logs structurés côté serveur pour le debug
• Monitoring d’erreurs avec Sentry ou équivalent
• Pages d’erreur custom (404, 500, 503)

async function envoyerEmail(data) {
  try {
    await transporter.sendMail(data);
    return { success: true };
  } catch (error) {
    console.error("[email] Échec envoi:", error);
    return { 
      success: false, 
      message: "L'envoi a échoué, réessayez ou contactez-nous directement." 
    };
  }
}

4. Charger 50 dépendances pour 3 lignes de code

Le symptôme

npm install moment lodash axios jquery uuid validator dompurify date-fns pour faire un site qui aurait pu être 100 % vanilla JavaScript moderne.

Pourquoi c’est grave

• Performance dégradée : chaque dépendance ajoute du JS au bundle final
• Surface d’attaque : chaque dépendance est une faille potentielle (cf. l’incident “left-pad”)
• Maintenance : il faut suivre les mises à jour de sécurité de toutes les libs
• Coût mémoire : un projet trivial peut atteindre 200 Mo de node_modules

La solution

• Vérifier d’abord si la fonctionnalité est dans la stdlib : Intl.DateTimeFormat au lieu de moment, Array.from au lieu de lodash.range, crypto.randomUUID() au lieu de uuid
• Choisir des libs petites et bien maintenues : utiliser Bundlephobia pour mesurer le poids
• Préférer les libs zero-deps quand possible
• Auditer régulièrement avec npm audit et npm outdated

JavaScript moderne (ES2022+) couvre 90 % des cas d’usage où on installait des libs il y a 5 ans.

5. Pas de stratégie d’indexation SEO

Le symptôme

Un site magnifique mais qui ne ranke jamais. Pourquoi ? Parce que :

• Aucun <title> ni <meta description> pertinent par page
• Pas de balise canonical
• Pas de sitemap XML
• Pas de robots.txt cohérent
• Aucune donnée structurée Schema.org
• Tous les liens en JavaScript pur (Googlebot ne les suit pas toujours)
• Site rendu uniquement côté client (Single Page App sans SSR)

Pourquoi c’est grave

Un site qui ne ranke pas, c’est un investissement marketing qui retombe dans le néant. Si vous avez payé 5 000 € pour un site, et qu’il ne génère que 50 visites/mois 6 mois après le lancement, c’est un échec retentissant.

La solution

• Métadonnées par page : title unique 50-60 chars, description 140-160 chars, mot-clé principal présent
• Sitemap XML auto-généré, soumis à Search Console
• robots.txt propre (interdire /api/, autoriser le reste)
• Schemas Schema.org : Organization, BreadcrumbList, Article, etc.
• SSR ou SSG : le contenu doit être visible sans JavaScript côté client
• URL propres : /blog/mon-article/, pas /?p=247
• Test avec Lighthouse : viser ≥ 95 en SEO

→ Voir notre guide Search Console pour TPE et notre guide Schema.org.

Comment savoir si votre site souffre de ces erreurs ?

Test rapide en 5 minutes

1. Console DevTools (F12 dans Chrome) → onglet Network. Rechargez la page. Vous voyez 50+ requêtes ? Bundle trop gros.
2. Vue source de la page (Ctrl+U). Vous voyez du HTML rempli ou juste <div id="root"></div> ? Si juste un <div> vide, votre site n’est pas SSR.
3. PageSpeed Insights : entrez votre URL. Score < 70 sur mobile = problème.
4. Soumettez un formulaire avec des caractères bizarres ('<>&). Si ça plante ou affiche un message d’erreur cryptique, validation manquante.
5. Tapez votre nom de marque dans Google. Vous n’apparaissez pas en première position ? Indexation problématique.

Si 3+ tests sur 5 sont négatifs, votre site a probablement des problèmes structurels.

La bonne approche : senior + junior

Un développeur junior peut écrire d’excellent code s’il est encadré. Le pattern qui fonctionne :

• 1 senior à plein temps ou en supervision sur le projet
• 1-2 juniors qui exécutent sous supervision
• Code review systématique avant merge
• Pair programming sur les parties critiques (sécurité, perf, SEO)
• Documentation à jour des décisions techniques

C’est le modèle qu’on applique chez CreativeWork. Notre pool de 30+ spécialistes mélange seniors expérimentés et juniors prometteurs, toujours encadrés.

---

Sources

• OWASP Top 10 Web Application Security Risks
• OWASP Input Validation Cheat Sheet
• Snyk State of Open Source Security Report
• Bundlephobia

---

Vous suspectez ces erreurs sur votre site actuel ? Notre audit SEO et technique à 150 € HT inclut une analyse de la qualité du code et des bonnes pratiques.