Recherche en minimalisme logiciel, une vision essentialiste du développement

Recherche en minimalisme logiciel, une vision essentialiste du développement

Cela fait 18 ans que je code, dont 10 ans en pro.
J’ai gratté et creusé des librairies de développement : Flask, CakePHP, Django, ExpressJS, NodeJs, Angular, 4D etc.
Parce que ce sont les bonnes pratiques, parce qu’il faut utiliser un ORM, parce qu’il faut isoler, respecter le DRY, le MVC, la programmation orientée objet (POO), et j’en passe…

On a empilé les normes, les raccourcis, les dépendances et les couches.
On a troqué le code spaghetti optimisé des anciens pour faire du joli code.
Fameux joli code, utilisant lui-même du code spaghetti mais planqué dans les méandres des frameworks et dépendances sans fin, écrits par d’autres.

Le revers de la médaille

À force de penser aux développeurs, on a atteint le summum de la lenteur et de l’aberration. 🔥
On est passés d'applications capables de traiter 600 à 1000 requêtes par seconde à peine 100, sur des machines équivalentes — et parfois, l'écart est encore bien plus dramatique. On scale horizontalement des applications médiocres, empilant des stacks hypertrophiées, car les moteurs applicatifs sont intrinsèquement lents.
On fait les riches avec de la « puissance » alors que la planète brûle. 🌍🔥
On gaspille toujours plus d’énergie pour masquer notre médiocrité et notre incapacité à aller à l’essentiel.

Une posture de recherche

Je profite de mon statut d’indépendant pour faire de la recherche.
Je creuse le concept du minimalisme appliqué à l’architecture logicielle.
C’est une aventure : une page blanche, des performances de dingue 🚀, une réduction drastique du coût d’hébergement et de maintenance.

Mais aller à contre-courant, c’est difficile.
Je voulais déjà faire cela à mes débuts, mais on me prenait pour un fou 🤪
Alors j’ai abdiqué, étudié, appliqué — notamment les design patterns et autres sucreries du monde des ego-développeurs.

Une expérience du terrain

J’ai l’expérience des gros projets, du code legacy, de la refacto, de la dette technique.
Je sais ce que je quitte, je sais pourquoi je le quitte.
Ma plus grande difficulté aujourd’hui : ne pas reconstruire un framework « maison ».

Les frameworks actuels sont excellents car maintenus par des milliers de contributeurs.
Les recréer serait refaire mal ce qui est déjà bien fait.

Revenir à l’essentiel

Le vrai danger, c’est de chercher à se simplifier la vie à court terme.
On empile des objets, des fonctions, des outils, et on finit par créer de la complexité là où il ne devrait y avoir que clarté.

Quand je parle avec d’autres développeurs, on me parle de "beau code", d’art.
Pour moi, le plus beau code est celui que je lis sans avoir à plonger dans 50 fichiers.
Celui qui fait simplement ce qu’on lui demande : traiter, afficher, exploiter, stocker.

Les monstres modernes

J’ai vu des ERP si configurables qu’ils deviennent eux-mêmes des univers de programmation.
Ils consomment plus de ressources pour se porter que pour traiter le métier.

L’IA ne va pas améliorer ça. Elle recycle les pratiques dominantes.
Elle empile les dépendances, pensant bien faire. 🤖

Un choix conscient

Je n’utilise plus de frameworks. J’ai tout abandonné : Django, Flask, Slim…
J’ai retrouvé l’esprit du débutant. L’esprit épuré. Faire simple.
Coder comme il y a 15 ans : du code direct, naïf mais efficace.

Je doute beaucoup. La tentation du confort et la sécurité du cadre est forte.
Rester dans le cadre rassure. On se sent embauchable. On suit le groupe. Avec un framework, on évolue dans un contexte sécurisé, où tout existe déjà.
On assemble, on a des kits de démarrage et des commandes magiques, tout est "donné" du moment qu'on accepte de rentrer dans le moule.
J'essaie au maximum, dans toute chose de ma vie, de ne pas dépendre de quoi que ce soit que je ne puisse pas assumer.
J'aime vendre des logiciels bâtis sur des briques que je maîtrise et que je peux assumer pour la maintenance à long terme.
Mais en choisissant une voie plus difficile, je sais qu'il faudra recruter des profils techniques exigeants, capables de coder sans filet.

Des pistes radicales

Je vais plus loin que l’abandon des ORM.
Je remets en question la notion même d’« entité ».
Passer par une phase de conversion d’un tableau brut en objet instancié est l’une des principales sources de lenteur.

Les applications n'ont pas forcément besoin de manipuler les objets pour afficher ou modifier la donnée — cela dépend du contexte.
Parfois, elles ne font qu’échanger des flux de données ciblés.
Charger de lourdes entités pour orchestrer des interactions entre objets complexifie inutilement l’ensemble.
En ce moment, je travaille à supprimer complètement les entités.
Les modèles valident, transforment et manipulent uniquement des tableaux (la forme réelle des données, telle qu’elle est stockée en base et renvoyée par les drivers).
On verra ce que ça donne, mais c’est déjà beaucoup plus direct.
La donnée doit être pensée par rapport à la vue.
Quand une vue s’affiche, elle appelle un ensemble de champs — inutile de tout encapsuler pour ça.

Je considère désormais la base de données comme un tout : un système de stockage accessible et modifiable directement.
Le schéma et la validation sont déjà pris en charge par la base de données relationnelle.
Je creuse l’idée que mes applications doivent dialoguer avec la base de données de manière directe, sans passer par une logique abstraite d’objet.
Le cœur des applications, ce sont des tableaux : une représentation directe des données réelles.
L’application doit être responsable de la validation des données, dans le format et le langage de la base de données, sans que des mécanismes de sérialisation ou de désérialisation viennent interférer entre la base de données et l’application.


Un appel aux silencieux

Je ferai des articles plus précis sur tout cela, y compris mes erreurs.
Ceux qui ne sont pas d’accord ne m’intéressent pas.
Je connais déjà les arguments. Je les ai trop entendus. Ils m’ont ralenti.

Mais vous, les silencieux qui expérimentez dans votre coin 👀
Votre avis m’intéresse vraiment.


Pour commenter : voir sur Linkedin

PS : j'ai exactement la même démarche de recherche de simplicité dans ma micro-exploitation agricole en maraîchage, au potager.

Merci pour votre lecture.
À bientôt, peut être 😉️
Chris