Add new article about complexity-is-the-lazy-solution

content/fr/post/plaidoyer-simplicite-ingenierie-logicielle/index.md

@@ -0,0 +1,190 @@
+---
+title: La complexité est devenue la solution paresseuse
+date: !!timestamp '2026-03-13T15:08:00+07:00'
+translationKey: complexity-lazy-solution
+tags:
+- architecture
+- infrastructure
+- cloud
+---
+
+En informatique, la complexité est souvent perçue comme un signe de professionnalisme.
+
+Un système simple paraît suspect, tandis qu'un système complexe paraît sérieux.
+
+<!-- more -->
+
+## Une décennie de réussites ne suffit pas à convaincre
+
+En dernière année d'école d'ingénieurs, j'ai construit une plateforme de CTF.
+À l'époque, il n'existait pas d'outil comme CTFd.
+Il fallait donc tout faire soi-même.
+
+J'ai fait des choix simples : servir des fichiers statiques pour réduire la surface d'attaque, générés lorsque nécessaire ; les services Unix classiques faisaient le lien entre les briques, les conteneurs bas niveau isolaient les services entre eux.
+
+La première année a été un peu chaotique, comme tout premier jet.
+Mais d'itération en itération, le système s'est stabilisé.
+Quelques "micro-services" bien découpés sont venus structurer les parties critiques.
+Et pendant dix ans, cela a tourné comme du papier à musique.
+Pas d'incident majeur.
+Pas de coupure à cause d'un service mal maîtrisé qui tombe.
+
+Pourtant, à chaque fois que je présentais l'architecture, je me heurtais aux mêmes questions :
+
+- Pourquoi il n'y a pas Kubernetes ?
+- Pourquoi utiliser le système de fichiers comme ça ?
+- Pourquoi il n'y a pas d'API REST ?
+
+Je n'ai jamais réussi à convaincre.
+Quand je suis parti, mon travail a été mis à la poubelle.
+
+La nouvelle solution repose sur CTFd : un produit générique qui nécessite beaucoup plus de puissance de calcul, offre moins de fonctionnalités, une interface austère et tourne bien sûr sur Kubernetes.
+
+Depuis, je me pose la même question : **pourquoi l'industrie informatique valorise-t-elle la complexité plutôt que la simplicité ?**
+
+
+## La complexité est devenue la réaction par défaut
+
+Aujourd'hui, face à un problème technique, la réaction instinctive est presque toujours la même : ajouter.
+Plus de machines, plus de couches logicielles, plus de cloud, plus d'abstractions.
+
+Le CPU est à 100 % ? On ajoute du CPU.\
+Le système est lent ? On migre vers le cloud.\
+L'architecture ne plaît pas ? On passe aux microservices.
+
+Mais ces décisions sont souvent prises avant même d'avoir compris le problème.
+**Quand un système devient lent, la réaction moderne est d'ajouter des serveurs. La réaction d'un ingénieur devrait être de se demander pourquoi.**
+
+Dire « c'est lent » n'est pas un diagnostic.
+C'est l'aveu que l'on a perdu la maîtrise de son système.
+
+
+## Un système simple est un système maîtrisé
+
+Je ne prône pas l'absence de technologie.
+Un système simple n'est pas un système rudimentaire.
+C'est un système où chaque élément a une raison d'exister.
+
+Un système maîtrisé, c'est un système où :
+
+- on sait pourquoi le CPU est saturé ;
+- on sait pourquoi on a besoin d'une carte réseau supplémentaire ;
+- on sait pourquoi un disque plus rapide est nécessaire ;
+- les coûts sont réellement compris, pas juste « 10 % de moins que le mois dernier ».
+
+C'est l'inverse de ce que je constate dans beaucoup d'entreprises.
+À commencer par les interfaces des fournisseurs de cloud : censées représenter l'état de l'art, elles sont elles-mêmes d'une lenteur frustrante.
+
+Quand les outils qui vous vendent de la performance ne sont pas performants, il devrait y avoir comme un signal.
+
+
+## Le paradoxe du professionnalisme
+
+Dans beaucoup d'organisations, la complexité est devenue un marqueur de sérieux.
+
+J'ai vécu ça de l'intérieur.
+Mon architecture Unix, mes fichiers statiques, mes micro-services légers : tout cela était perçu comme du bricolage.
+Pendant que les autres organisateurs dans l'événement se battaient avec leurs serveurs et CTFd, mon système tournait sans problème.
+
+Pourtant pour l'exécutif, si du "bricolage d'ingénieur" fonctionne pendant 10 ans, c'est que ce n’est pas si compliqué.
+
+À l'inverse, une stack avec Kubernetes, Kafka et un service mesh sera immédiatement perçue comme « une vraie architecture ».
+Même si personne dans l'équipe ne la comprend finement.
+
+**Un système simple paraît amateur. Un système complexe paraît professionnel.**
+
+Ce phénomène a plusieurs racines.
+Il y a le mimétisme : on copie les architectures de Netflix et Google sans considérer leurs contraintes.
+C'est l'équivalent de construire une cuisine de restaurant trois étoiles pour faire des pâtes.
+
+Il y a la peur du blâme : si le système casse et qu'on utilise « les standards de l'industrie », personne ne sera pointé du doigt.
+
+Et il y a l'effet CV : travailler avec Kubernetes et Kafka, ça valorise une carrière. Postgres et un monolithe, beaucoup moins.
+
+
+## Le *custom* ne disparaît pas, il se déplace
+
+Quand mon système a été remplacé par CTFd, au profit de la standardisation, le non-standard n'a pas disparu.
+Il a juste changé d'endroit.
+
+Certes le cœur est devenu un produit générique, mais tout ce qu'il y a autour : l'orchestration, les scripts, le scotch, les adaptations, sont devenus le nouveau *custom*.
+
+Et ce code-là est souvent pire : moins cohérent, plus dispersé, moins réfléchi globalement.
+On remplace un système pensé comme un tout par une accumulation de couches de contournement.
+
+C'est très courant avec les architectures modernes.
+On ne supprime pas la "complexité", on la déplace dans des endroits moins visibles et moins maîtrisés.
+Pire encore, il faut suivre les évolutions du standard constamment : adapter ses personnalisations, lutter contre les changements structurels, prier pour [les bonnes âmes](https://news.ycombinator.com/item?id=46136023).
+
+
+## Le cloud comme solution paresseuse
+
+Suite logique, le cloud est aujourd'hui la principale solution paresseuse.
+Non pas parce qu'il est inutile, il a des cas d'usage légitimes, mais parce qu'il permet de masquer les problèmes au lieu de les résoudre.
+
+Face à un problème technique, il y a deux chemins.
+Le premier : mesurer, comprendre, analyser.
+Le second : ajouter des ressources, empiler des abstractions, déplacer le problème.
+Pourquoi le second chemin est devenu la norme ?
+
+**Ajouter des machines est souvent plus facile que comprendre un programme.**
+
+Et c'est là que se situe la vraie paresse.
+Pas dans le choix d'un hébergement simple ou d'une architecture légère.
+Mais dans le refus de comprendre ce qui se passe réellement dans le système.
+
+
+## Le minimalisme n'est pas l'absence de complexité
+
+Certains systèmes sont extrêmement complexes et c'est normal.
+Le moteur de recherche de Google, les enchères publicitaires temps réel de Criteo, ... : ce sont des systèmes chirurgicaux où chaque brique est justifiée, parfois plusieurs fois.
+
+C'est exactement cela, le minimalisme en ingénierie : ne garder que la complexité indispensable.
+
+**La complexité n'est pas un problème. La complexité inutile en est un.**
+
+Une start-up avec quelques milliers d'utilisateurs et une équipe de cinq développeurs n'a pas les mêmes contraintes que Netflix.
+Pourtant, beaucoup déploient les mêmes architectures.
+
+
+## L'IA rend ce problème encore plus urgent
+
+Aujourd'hui, les outils d'IA savent produire du code et des architectures à une vitesse inédite.
+On peut générer un système entier en quelques heures.
+Cela veut dire que **la production de complexité n'a jamais été aussi facile**.
+
+Dans ce contexte, la compétence essentielle change.
+Elle n'est plus seulement de savoir coder.
+Elle est de savoir contenir la complexité produite.
+De rester en position de réflexion plutôt que de foncer tête baissée vers la première solution générée.
+
+L'IA est un outil formidable pour pivoter rapidement vers des solutions alternatives, pour explorer des approches différentes.
+Mais encore faut-il avoir le recul nécessaire pour choisir la bonne.
+
+**Les machines apprennent à produire de la complexité. Les ingénieurs doivent apprendre à la contenir.**
+
+
+## Le rôle réel de l'ingénieur
+
+Un ingénieur n'est pas un producteur de code.
+Son rôle est de comprendre les systèmes, de maîtriser les ressources et d'éliminer la complexité inutile.
+
+Un très bon ingénieur fait souvent *moins*.
+Un système bien conçu paraît presque trop simple.
+Et c'est précisément pour ça qu'il n'est pas reconnu : **le succès efface la perception de la difficulté.**
+
+Quand tout marche depuis dix ans, les gens finissent par penser que ça n'a pas dû être bien compliqué.
+
+Comme je l'entends parfois : aujourd'hui, la compétence la plus rare en informatique n'est pas d'écrire du code. C'est de savoir ne pas en écrire.
+
+
+## La simplicité est une discipline
+
+La simplicité n'est pas une absence de technologie.
+C'est le résultat d'un travail d'ingénierie exigeant.
+Ça demande de la mesure, de l'observation, de la réflexion.
+Ça demande parfois de résister à la pression sociale qui pousse vers la complexité.
+
+Et dans un monde où les machines savent générer des systèmes toujours plus complexes, la responsabilité de l'ingénieur est de garder ces systèmes compréhensibles.
+
+**La simplicité n'est pas de l'amateurisme. C'est ce que l'ingénierie produit quand elle devient mature.**