Au début, je pensais que mon rôle d’ingénieur backend consistait à construire plus. Plus de lignes de code. Plus de services. Plus de logique. Mais en réalité, l’essentiel du métier, c’est souvent de décider ce qu’on peut éviter de coder. J’ai longtemps cru qu’un bon backend, c’était des architectures ambitieuses et des designs "intelligents". Avec le temps, j’ai compris que : • Ce service indépendant qu’on voulait créer ? Une simple fonction partagée aurait suffi. • Cette mécanique de configuration ultra-flexible ? Personne ne l’a jamais utilisée. • Cette API que j’avais prévu de découper en 4 modules ? Un seul endpoint suffisait. Aujourd’hui, j’essaie toujours de me poser cette question avant de me lancer : Quelle est la solution la plus claire, rapide et stable pour répondre au besoin réel ? Pas la plus élégante sur le papier. Pas la plus "scalable" en théorie. Juste celle qui fonctionne, qu’on comprend demain matin, et qu’on n’a pas peur de maintenir. Parce que dans la durée, la simplicité gagne toujours. Et la complexité inutile, elle, finit par coûter bien plus cher qu’on ne l’imagine.