En informatique, la complexité est souvent perçue comme un signe de compétence.
En effet, un système simple paraît suspect, tandis qu’un système complexe paraît sérieux.
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 de logiciel comme CTFd. Il fallait donc tout faire soi-même.
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. 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. 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, j’entendais les mêmes questions sur un air dubitatif :
- Pourquoi n’y a-t-il pas Kubernetes ?
- Pourquoi utiliser le système de fichiers ainsi ?
- Pourquoi pas une simple API REST ?
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. 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 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 à 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 déplace l’ensemble vers le cloud.
L’architecture déplaît ? On passe aux microservices.
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 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 de la perte de maîtrise de son système.
Un système simple est un système maîtrisé
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é est un système où :
- on sait pourquoi le processeur est saturé ;
- on sait pourquoi ajouter une carte réseau ;
- on sait pourquoi un disque plus rapide est nécessaire ;
- on comprend le détail des coûts, pas juste « 10 % de moins que le mois dernier » à tout hasard.
Cela vous semble logique ? Pourtant, je constate l’inverse dans beaucoup d’entreprises. À 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 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. Cela vous parle ?
Je l’ai vécu de l’intérieur. Mon architecture Unix, mes fichiers statiques, mes micro-services légers : tout était perçu comme du bricolage. 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, vu de l’extérieur, du “bricolage d’ingénieur” qui fonctionne pendant 10 ans ne peut pas être si compliqué !
À 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 ceux qui la comprennent finement sont rares.
Un système simple paraît amateur. Un système complexe paraît professionnel.
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.
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 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 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 changé d’endroit.
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.
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.
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, il faut constamment suivre les évolutions du logiciel “standard” en adaptant ses personnalisations, en luttant contre les changements structurels, priant pour les bonnes âmes.
Le cloud comme solution paresseuse
Suite logique de cette tendance, le cloud est aujourd’hui la principale solution paresseuse. 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.
Le premier : mesurer, comprendre, analyser.
Le second : ajouter des ressources, empiler des abstractions, déplacer le problème.
Pourquoi ce second chemin est-il devenu la norme ?
Ajouter des machines est souvent plus facile que comprendre un programme.
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, mais dans le manque de volonté de comprendre comment le tout fonctionne, et ce qui se passe dans le système.
Le minimalisme n’est pas l’absence de complexité
Certains systèmes sont complexes et c’est normal. 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 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’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. En conséquence, la production de complexité n’a jamais été aussi facile.
Dans ce contexte, la compétence change. Elle n’est plus de savoir coder, elle devient 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.
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 de l’ingénieur
Un ingénieur n’est pas qu’un producteur de code. Son rôle consiste à comprendre les systèmes, à maîtriser les ressources, les coûts et à éliminer la complexité inutile.
Un bon ingénieur fabrique souvent moins. 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é.
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.
La simplicité est une discipline
Je ne confonds pas la simplicité avec une absence de technologie. Disons qu’elle est le résultat d’un travail d’ingénierie exigeant. 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é.
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.