4 erreurs de développeur que j’ai faites (et comment elles m’ont rendu meilleur)

Quand j’ai commencé à coder, j’avais cette énergie débordante et l’ego du dev sûr de lui 💪. Mais la dure réalité, c’est qu’on apprend beaucoup plus de nos erreurs de développeur que de nos succès. Cet article est un recueil de mes 4 plus grosses erreurs à ce jour — classées ici par niveau de gravité, avec ce que j’en ai tiré pour devenir plus efficace, professionnel et zen dans mon travail.

Erreur n°1 — Ne pas utiliser les bons outils : mon API WordPress bricolée

Quand j’ai débuté la construction d’une petite API pour mon site perso https://un-roliste-flemmard.com (pour mon générateur de noms), j’ai tout fait à la main… vraiment n’importe comment 🤦‍♂️.

Ce que j’ai fait (et raté)

Je voulais renvoyer des données JSON depuis WordPress, mais au lieu d’utiliser l’API prévue à cet effet, j’ai transformé un modèle de page de thème en endpoint. Résultat : galères de structures, sécurité bancale et des semaines de frustration.

Ce que j’aurais dû faire

WordPress fournit une REST API native avec un système de routes et d’endpoints qu’on peut étendre proprement directement dans un plugin ou un thème. Il suffit d’utiliser register_rest_route() et les hooks appropriés plutôt que de réinventer la roue.

Leçon retenue

Avant de commencer à coder quelque chose « from scratch » :
✔️ Regarde les outils que la plateforme offre déjà
✔️ Cherche les meilleures pratiques et documentations officielles
Cela t’évitera souvent des semaines de dépanne et de refactoring 😅.

Erreur n°2 — Mauvaise approche des données : recherche inefficace sur un ERP

Pendant que je bossais sur l’ERP Open-Prod pour Objectif-PI, on m’a demandé un outil de recherche dans la documentation. Pour mon premier « vrai » code pro, j’ai fait ce que tout dev un peu naïf ferait : j’ai chargé toutes les pages, puis pour chaque page j’ai extrait tous les blocs de texte, puis cherché le terme voulu en JavaScript… Et ça fonctionnait…

Puis la réalité a frappé

Un an plus tard, en production, le truc devenait si lent que ça prenait des minutes ou des heures 😬.

Comment j’ai corrigé ça

✔️ Je suis parti de la donnée plutôt que de la vue.
✔️ J’ai déplacé une partie du travail directement dans la base : filtrer avec SQL plutôt que dans le navigateur.
✔️ J’ai ciblé uniquement les données pertinentes avant de les afficher.

✔️ On est passé de minutes/heures à une dizaine de secondes de réponse.

👉 Il vaut presque toujours mieux interroger intelligemment la base plutôt que charger tout et filtrer ensuite, surtout sur de gros volumes (l’exemple est donné en PHP ici, mais ça vaut pour tout les langages, et a la fois pour le front et le back).

La vraie leçon

Penser comme un utilisateur plutôt que comme un système de données est souvent ce qui fait dérailler les performances.

Erreur n°3 — Charger trop de données en mémoire : la leçon apprise sur le terrain

Pendant mon stage au Parc National des Écrins, j’ai développé une appli de référencement d’espèces avec une carte offline (parce qu’il n’y a pas de réseau à l’intérieur du parc, pour des raisons évidentes).

Le problème

J’ai tenté de charger un fichier de tuiles de carte ENTIÈREMENT en mémoire. Sur un téléphone avec 2Go de RAM, devine quoi ? 😵‍💫 Ça plante ou ça lag trop.

La vraie solution

Plutôt que de charger tout le fichier en RAM, j’ai :
✔️ décompressé le fichier,
✔️ donné à l’outil de cartographie les chemins vers les images comme s’il s’agissait d’URLs.

Résultat : la carte s’affiche sans lag, même quand elle est grosse.

Leçon retenue

Sur mobiles, la mémoire est une ressource critique. Il faut penser streaming / lazy-loading / découpage des données pour garder une application fluide.

Erreur n°4 — Commettre trop vite : la pression du manager… et mes fautes d’inattention

Oui, je l’avoue : il m’arrive encore parfois de commettre du code pas assez testé juste pour « avancer vite ». Ça arrive souvent sous pression, mais aussi par habitude 👨‍💻

Pourquoi c’est risqué

Un commit précipité peut finir en production et casser des choses. Heureusement souvent mineur, mais jamais bon.
Rappelle-toi : un commit devrait idéalement ne pas casser le build.

Comment j’ai limité ça

✔️ Avant chaque grosse modif, je fais un mini-tour de l’appli pour vérifier que rien ne casse.
✔️ J’implémente des tests automatisés quand c’est possible (TDD, unit tests, etc.).
✔️ Je m’oblige à des commits plus petits et logiques plutôt que des gros blobs de code.

Leçon retenue

Prendre le temps d’écrire et tester est un vrai facteur de productivité sur le long terme, même si ça prend juste un peu plus de temps au début.

Conclusion : transformer chaque erreur de développeur en levier d’amélioration

On se retrouve tous face à des erreurs — que ce soit le fait de ne pas utiliser les bons outils, de mal penser les requêtes de données, de sous-estimer les contraintes hardware ou de commettre trop vite. Ce qui différencie un développeur junior d’un pro, c’est souvent la capacité à apprendre des erreurs, puis à ajuster son workflow pour ne pas refaire les mêmes.

Si tu veux aller plus loin dans la création d’outils web performants, bien pensés et maintenables, je peux t’aider 🚀
👉 De la création de site web au développement spécifique, en passant par l’audit ou la maintenance, je peux te proposer une solution adaptée à ton projet.

Contacte-moi pour en discuter !