Improve wording

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

@@ -8,183 +8,200 @@ tags:
 - cloud
 ---
 
-En informatique, la complexité est souvent perçue comme un signe de professionnalisme.
+En informatique, la complexité est souvent perçue comme un signe de compétence.
 
-Un système simple paraît suspect, tandis qu'un système complexe paraît sérieux.
+En effet, 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
+## Quelle est la valeur d'une décennie de réussites ?
 
 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.
+À l'époque, il n'existait pas de logiciel comme [CTFd](https://github.com/CTFd/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.
+Il m'a fallu beaucoup réfléchir pour débuter une architecture qui apparait simple a posteriori : servir des fichiers statiques, générés lorsque nécessaire, pour réduire la surface d'attaque.
+Les services Unix standards faisaient le lien entre les composants.
+Les conteneurs de 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é.
+D'amélioration en amélioration, j'ai réussi à stabiliser le système.
 Quelques "micro-services" bien découpés sont venus structurer les parties critiques.
-Et pendant dix ans, cela a tourné comme du papier à musique.
+Pendant dix ans, l'ensemble était réglé 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 :
+Pourtant, chaque fois que je présentais l'architecture, j'entendais les mêmes questions sur un air dubitatif :
 
-- Pourquoi il n'y a pas Kubernetes ?
+- Pourquoi n'y a-t-il pas Kubernetes ?
-- Pourquoi utiliser le système de fichiers comme ça ?
+- Pourquoi utiliser le système de fichiers ainsi ?
-- Pourquoi il n'y a pas d'API REST ?
+- Pourquoi pas une simple API REST ?
 
-Je n'ai jamais réussi à convaincre.
+Voici la réponse à la question sur la valeur d'une décennie de réussite : je n'ai jamais réussi à convaincre.
+Une décennie de succès n'y a pas suffit.
 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.
+La nouvelle solution repose sur CTFd.
+Autrement dit, un produit générique qui nécessite plus de puissance de calcul, offre moins de fonctionnalités, affiche 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é ?**
+Depuis, je me pose la 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.
+Aujourd'hui, face à une difficulté technique, la réaction 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.\
+Le système est lent ? On déplace l'ensemble vers le cloud.\
-L'architecture ne plaît pas ? On passe aux microservices.
+L'architecture déplaît ? On passe aux microservices.
 
-Mais ces décisions sont souvent prises avant même d'avoir compris le problème.
+Selon mes observations, 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.**
+**Quand un système devient lent, la réaction instinctive consiste à ajouter des serveurs, des ressources, alors que 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.
+C'est l'aveu de la perte de 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.
+La phrase la plus destructrice qui m'alerte dorénavant et que je vous encourage à repérer comme un gyrophare rouge quand vous l'entendez : « on va faire simple ! »
+
+Pourquoi ?
+
+Parce que celui qui la prononce confond souvent « simple » avec « simpliste ».
+En général, il n'est pas du métier.
+
+Entendons-nous bien : 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ù :
+Un système maîtrisé est un système où :
 
-- on sait pourquoi le CPU est saturé ;
+- on sait pourquoi le processeur est saturé ;
-- on sait pourquoi on a besoin d'une carte réseau supplémentaire ;
+- on sait pourquoi ajouter une carte réseau ;
 - 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 ».
+- on comprend le détail des coûts, pas juste « 10 % de moins que le mois dernier » à tout hasard.
 
-C'est l'inverse de ce que je constate dans beaucoup d'entreprises.
+Cela vous semble logique ? Pourtant, je constate l'inverse 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.
+À commencer par les interfaces des fournisseurs de cloud.
+Elles sont censées représenter l'état de l'art, alors qu'elles sont d'une lenteur frustrante.
 
-Quand les outils qui vous vendent de la performance ne sont pas performants, il devrait y avoir comme un signal.
+Quand les fournisseurs qui vous vendent de la performance ne sont pas performants, il devrait y avoir comme un signal dans notre tête.
 
 
 ## Le paradoxe du professionnalisme
 
-Dans beaucoup d'organisations, la complexité est devenue un marqueur de sérieux.
+Dans beaucoup d’organisations, la complexité est devenue un marqueur de sérieux. Cela vous parle ?
 
-J'ai vécu ça de l'intérieur.
+Je l’ai vécu de l’intérieur.
-Mon architecture Unix, mes fichiers statiques, mes micro-services légers : tout cela était perçu comme du bricolage.
+Mon architecture Unix, mes fichiers statiques, mes micro-services légers : tout é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.
+Pendant que les autres organisateurs de l’événement se battaient avec leurs serveurs et le logiciel CTFd, mon système tournait comme une horloge.
 
-Pourtant pour l'exécutif, si du "bricolage d'ingénieur" fonctionne pendant 10 ans, c'est que ce n’est pas si compliqué.
+Pourtant, vu de l’extérieur, du "bricolage d’ingénieur" qui fonctionne pendant 10 ans ne peut pas être si compliqué !
 
-À l'inverse, une stack avec Kubernetes, Kafka et un service mesh sera immédiatement perçue comme « une vraie architecture ».
+À l’inverse, un base qui repose sur Kubernetes, Kafka et un service mesh sera aussitôt perçu comme « une vraie architecture ».
-Même si personne dans l'équipe ne la comprend finement.
+Même si ceux qui la comprennent finement sont rares.
 
 **Un système simple paraît amateur. Un système complexe paraît professionnel.**
 
-Ce phénomène a plusieurs racines.
+Selon moi, ce phénomène a plusieurs racines. J’en ai repéré plusieurs et il en manque peut-être.
+
 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.
+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.
+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.
+Il y a l’effet CV : travailler avec Kubernetes et Kafka valorisent une carrière. Postgres et un monolithe, beaucoup moins.
+
+Il y a enfin l’abondance de moyens bon marché.
+Pourquoi économiser le stockage quand le prix des disques diminue ?
+Pourquoi économiser la mémoire vive quand l’ajout coûte quelques dizaines d’euros ?
+Pourquoi économiser de la puissance de calcul quand elle est disponible à volonté ?
+Oui, faire simple coûte du temps de personnel compétent, qui sont des ressources rares et chères.
 
 
 ## 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.
+Quand mes successeurs ont remplacé mon système par le logiciel CTFd avec l'intention de la standardisation, le non-standard n'a pas disparu.
-Il a juste changé d'endroit.
+Il a 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*.
+Certes, le cœur du système est devenu un logiciel générique.
+Mais tout ce qui le complète comme 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.
+Devinez quoi ? Ce code-là est souvent pire, car 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.
+Cet exemple est 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).
+Pire, il faut constamment suivre les évolutions du logiciel "standard" en adaptant ses personnalisations, en luttant contre les changements structurels, priant 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.
+Suite logique de cette tendance, 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.
+Pas parce qu'il est inutile, car il est légitime pour certains usages, mais parce qu'il permet de masquer les problèmes au lieu de les résoudre.
+
+Face à un problème technique, je vois deux chemins.
 
-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 ?
+
+Pourquoi ce second chemin est-il devenu la norme ?
 
 **Ajouter des machines est souvent plus facile que comprendre un programme.**
 
-Et c'est là que se situe la vraie paresse.
+Il me semble que la paresse se situe ici.
-Pas dans le choix d'un hébergement simple ou d'une architecture légère.
+Pas dans le choix d'un hébergement simple ou d'une architecture légère, mais dans le manque de volonté de comprendre comment le tout fonctionne, et ce qui se passe dans le système.
-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.
+Certains systèmes sont 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.
+Le moteur de recherche de Google, les enchères publicitaires en temps réel de Criteo sont des systèmes chirurgicaux où chaque élément est justifié, 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.
+Une entreprise qui démarre, 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.
+Aujourd'hui, les outils d'intelligence artificielle 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**.
+En conséquence, **la production de complexité n'a jamais été aussi facile**.
 
-Dans ce contexte, la compétence essentielle change.
+Dans ce contexte, la compétence change.
-Elle n'est plus seulement de savoir coder.
+Elle n'est plus de savoir coder, elle devient de savoir contenir la complexité produite.
-Elle est de savoir contenir la complexité produite.
+Il s'agit de s'obliger à réfléchir, plutôt que de foncer tête baissée vers la première solution proposée.
-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.
+L'intelligence artificielle est un outil formidable pour pivoter vite vers des solutions alternatives ou 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
+## Le rôle de l'ingénieur
 
-Un ingénieur n'est pas un producteur de code.
+Un ingénieur n'est pas qu'un producteur de code.
-Son rôle est de comprendre les systèmes, de maîtriser les ressources et d'éliminer la complexité inutile.
+Son rôle consiste à comprendre les systèmes, à maîtriser les ressources, les coûts et à éliminer la complexité inutile.
 
-Un très bon ingénieur fait souvent *moins*.
+Un bon ingénieur fabrique souvent *moins*.
-Un système bien conçu paraît presque trop simple.
+Un système bien conçu paraît presque trop simple et c'est souvent pour ça qu'il n'est pas reconnu : **le succès efface la perception de la difficulté.**
-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é.
+Aujourd'hui, la compétence la plus rare en informatique n'est pas d'écrire du code, c'est de savoir éviter d'en écrire.
-
-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.
+Je ne confonds pas la simplicité avec une absence de technologie.
-C'est le résultat d'un travail d'ingénierie exigeant.
+Disons qu'elle est le résultat d'un travail d'ingénierie exigeant.
-Ça demande de la mesure, de l'observation, de la réflexion.
+Cette exigence demande de la mesure, de l'observation, de la réflexion et parfois de résister à la pression sociale qui pousse vers la complexité.
-Ç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.
+Dans un monde où les Hommes et les machines savent générer des systèmes complexes, la responsabilité de l'ingénieur consiste à 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.**