Comment éviter de gaspiller votre budget sur des solutions complexes
De mon expérience terrain, le sur-engineering est l'un des problèmes courants de nombreuses startups.
De même si toute votre architecture repose sur un seul développeur car il est le seul à comprendre le code, vous êtes dans une situation très dangereuse.
Traduction : "Je résous des problèmes que nous n'avons pas encore et que nous n'aurons peut être jamais"
Traduction : "J'ai lu un article sur Netflix/Uber et je pense que ça s'applique à nous"
Reality check : Netflix a des millions d'utilisateurs, vous en avez quelques centaines.
Traduction : "J'aime les architectures complexes"
Paradoxe observé : Plus l'architecture est "maintenable" en théorie, moins l'équipe arrive à maintenir le produit en pratique.
Traduction : "J'optimise avant de mesurer"
Exemple marquant : E-commerce avec cache sophistiqué (Redis + Varnish + CDN) pour... 12 commandes par jour.
Traduction : "Je ne veux pas réfléchir au contexte spécifique et à mes besoins"
Traduction : "Je préfère résoudre des problèmes hypothétiques plutôt que des vrais problèmes"
Traduction : "J'ajoute de la complexité au nom de la sécurité"
Avant chaque décision technique :
Il est tout à fait possible d'anticiper certains problèmes, mais uniquement si deux conditions sont remplies :
La solution ne doit pas ajouter de complexité significative au projet
L'essentiel de l'équipe ne doit pas avoir besoin de formation pour comprendre la solution
Commencer avec un seul serveur sur une plateforme comme Clever Cloud qui permet un scaling automatique très simple et rapide. Pas de sur-ingénierie, juste une anticipation intelligente.
Mettre en place Kubernetes "au cas où" alors que personne dans l'équipe ne le maîtrise vraiment.
"Choose boring technology" - Dan McKinley (ex-Etsy)
Ma version : Utilisez la technologie la plus adaptée pour résoudre votre problème et pas forcément la plus à la mode.
Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains.
Steve Jobs
plusieurs millions d'utilisateurs avec Ruby on Rails monolithique
Résultat : Équipe de réduite, profitabilité depuis 20 ans
Architecture ultra-simple
Votre job n'est pas d'impressionner d'autres développeurs. Votre job est de résoudre des problèmes utilisateur avec le minimum de complexité.
Arrêtons de traiter le code comme une relique sacrée qu'il faudrait préserver à tout prix. Le code n'est pas un patrimoine immuable, c'est un outil jetable conçu pour résoudre des problèmes spécifiques dans un contexte donné.
Comme le souligne brillamment Quentin Adam dans son article sur la "dette technique", cette notion même de dette est une supercherie qui empoisonne notre façon de penser. Il n'y a pas de dette technique, il n'y a que des décisions d'investissement. Chaque ligne de code écrite est un pari sur l'avenir, pas un engagement éternel.
La beauté du développement logiciel réside paradoxalement dans l'art de la destruction créatrice. Supprimer du code devrait être un moment de joie, pas de culpabilité. Réécrire une fonctionnalité de zéro avec la connaissance acquise n'est pas un échec, c'est de l'investissement intelligent. Comme chez Clever Cloud où ils ont réécrit leur load balancer en deux jours après avoir passé huit mois sur une première version bugguée - l'expérience acquise était la vraie valeur, pas le code initial.
Votre code d'aujourd'hui, si sophistiqué soit-il, sera probablement obsolète demain. Et c'est parfait ainsi. Une équipe qui comprend intimement un métier après avoir "échoué" une première fois vaut infiniment plus que du code parfaitement architecturé mais inadapté aux vrais besoins.
Stop au sur-engineering. Construisons des tentes Quechua quand nous avons besoin d'un abri rapide, et gardons nos cathédrales pour les problèmes qui le méritent vraiment. Le code le plus élégant n'est pas celui qui impressionne les autres développeurs, c'est celui qui peut être jeté sans regret quand son temps est révolu.
Car au final, notre métier n'est pas de créer du beau code - c'est de résoudre des problèmes business.
Et parfois, la meilleure solution, c'est la touche "Suppr".
Je vous aide à identifier les vrais problèmes et à simplifier votre architecture
Audit technique • Refactoring intelligent • Architecture adaptée à vos besoins réels